Why is Tom Gilb so angry?
Having recently read some of Tom Gilb's papers on the state of Agile, do you think he is right? Has Agile fundamentally missed its goal and failed?
Essentially he is saying that Agile missed the mark of Business and Stakeholder Value. It is hard to judge the sincerity as it essentially leads to a discussion of their EVO method.
Google : 7 truths about Agile and Scrum that people don't want to hear.
And another point below.
"The Agile Manifesto  was never a well formulated document, from the point of view of making sure we did the right things right. I have at least, in my principles and values here, tried, in my not too humble opinion, to show a specific alternative – how it might have been. The manifesto has of course been successful in getting a wave of change. And moving to rapid iteration is a ‘good thing’. But rapidly iterating in wrong directions is not progress. The key idea of intelligent iteration towards well- defined stakeholder values, was clearly and extensively spelled out in Principles of Software Engineering Management, which most of the leading agile gurus point to as a source of some of their agile ideas. But as some of them reflect today, they missed at least one simple but essential point – ‘stakeholder value’ needs to be the guiding light for the iterative process – not functions and stories.
Hey, we are still a young discipline. We only wasted about a decade getting this wrong. Software has been seeing failed fads come and go for 50 years. We have so many experienced intelligent people now – maybe we can get it right in the next revolution?
If the IT-project failure rate (total plus partial) goes down from about 90% (Standish) to less than 2%, you will know we got it right, for a change. Do you think we can do it right by my 100th Birthday?
I notice this post after a read a recent post on LinkedIn by Gilb - “How do Gilb's Methods: Planguage and Evo align with Agile Manifesto?” (http://www.gilb.com/dl921) . Gilb's focus on delivering stakeholder value is a long term focus, so I would say he is sincere in his criticism. He also has a big concern about architecture, and how it is addressed in Scum. Personally I've seen agile projects deliver well in the right conditions, on the other hand I have seen them fail spectacularly when they failed to grasp what stakeholders want from a project and don't address architecture. In that sense I can understand his anger because these are not new concepts, and they should be addressed.
I don't think he's really saying anything of any substance.
Also, he says stuff like this:
The stakeholders are the one who should get value delivered incrementally, at the every increment of development. I believe that this should be the aim of each increment and not 'delivering working code to customers'. This means you need to recognize exactly which stakeholder type is projected to receive exactly which value improvement, and plan to have them, or a useful subset of them, on hand to get theincrement, and evaluate the value delivered. Current agile methods are not set up to do this, and in fact do not seem to care at all about value or stakeholders.
What a nonsense statement. His article is littered with that.
Seems like nonsense to me, especially his point about Agile and Scrum missing the mark.
Maybe I would agree with him if by "missing the mark", he meant, "3-10X more successful than waterfall based approaches.", then maybe... ;-)
(esp when 90% of Agile teams are Scrum teams)
Important to note that the first Gilb link above is from 2010. I'm not sure any criticism he has of Agile and Scrum is remotely valid. EVO might very well support the Agile Manifesto -- I make no claim about that.
But supporting the AM and actually succeeding are 2 different things. :-)
Oh, I think there's still something true with his critique. I've seen some projects doing "customer requirements" but completely ignoring stakeholder values. Read Tom's statements under Principle 3. It's not what should be done according to Scrum but many people out there do it that way - it's easier than to discuss what the requirements really are. This was the problem in traditional approaches and is still a problem, loaded upon POs as many developers just take the expressed words without checking their accordance to objectives and values or if they are requirements and not solutions or designs.
The other issue I come across all too often, is that many companies set developer = coder (sometimes mixed with testers) which is a complete missunderstanding of a Scrum development team. In those cases the silos are often at least as high as with old traditional companies. This is a glimpse of what Tom tries to address with "far too 'programmer centric'".
I don't think you have to use EVO to overcome these issues, but Tom is right in complaining. We all should recollect the Agile Manifest and it's implications. And he's right in his claim to see the overall picture and not only the code producing part: Fast iterations in the wrong direction won't take us to success!
Are not "customers" part of the "Stakeholders" that we seek to deliver value to?
As long as "customers" have the same understanding about SCRUM, Agile, LEAN etc. you're correct. Unfortunatley, a lot of minor companys havent any contact to frameworks like these....
I am not sure why customers need to know about any of those. They just want to get a solution for their problem.
Gojko Adzic gave an excellent talk on NDC a few years ago when he told a story of some SCRUM team working and delivering working code, with great velocity and conforming everything SCRUM tells them to do. All this just to find out that they were going full speed to a cliff, where the whole thing felt down and crashed. They spent all investor's money and delivered no value. This is what Tom Gilb is talking about.
I have no idea about Planguage and all this, I believe he tries to sell his methods and I am not sure how good or bad they are. But in pointing out that following the method is not enough and working software is not the real value is absolutely correct. Sometimes, the real value is not to create any software, for example.
Hi, I just discovered this Aug 2018 and thought I would answer.
I am angry on behalf of all the stakeholders we fail to give value to!
I do not have much of a hidden $ sales agenda, I am pensioned (now 77 years old) and not building income streams. I am an idealist. My books and papers and courses are largely freeware and shareware.
I am happy to discuss my ideas (and yours) by email, for serious knowledge seekers, who can be bothered to read a little bit before spouting off (unlike some commenters above). tom at gilb dot com. I will read your paper or slides before spouting off, out of respect for you, too.
My free downloads are at concepts.gilb.com/file24
My Competitive Engineering book link is http://www.gilb.com/dl541 (you pay for paper edition)
and my new digital only book on really advanced agile Value Planning if free for readers here at
The 112MB ‘Best' quality edition (more readable illustrations!)
For Alex, my skeptic above who does not give any reasons for his opinion, (see Evidence Based Scrum Alex , https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-09/EBMgt_Gui…)
who lives in London, and other willing travel there, I hold many FREE British Computer Society courses
and soon (this week of Aug 14th ) there will be posted the AGILE courses 2 x 2 days last week of Sept.
I also happily hold talks and seminars at Agile conferences. Here is my Keynote at Agile Istanbul recently
in a Lean and Agile Way
Keynote Talk at Agile Days Turkey, 12 April 2018, Slides:
The Keynote Video:
I don't have anything smart to add to the conversation, but just wanted to thank Tom for his input.
You may be a pensioner, Tom, but in many ways you are waaaaay younger and more passionate than quite a few active professionals.
Some People just hate Agile and think they can do it better. I see this as a rant more then good knowledge.
I guess Tom got a very valid point. The most important question is frequently missed - why? Why are we doing this? Why customers need this and that? This all brings us to the question about stakeholder value. And this is why I believe that if you want to use Scrum or any other framework, this is probably not enough.
I really loved the ideas of Lean some time ago - they add what's missing in Scrum from my point of view (and what is maybe the most important thing) - customer/stakeholder value orientation. And Tom gives another important input, which in my opinion supplements the whole idea of being Agile (or maybe brings us back to its core?).
Now, a bit about quantifying requirements - this is crucial. Really, really crucial. We talk a lot about the DoD, Acceptance Criteria, etc. When can we say something is ready and will bring value to the customer? Only when we can show that e.g. some service works 50% faster, so that our customers can buy a Christmas gift quicker in "rush hours" of online shopping for the whole family. And then we validate the idea with our stakeholders, in that case customers.
I guess it was Deming who said that "without data you're just another guy with an opinion". As Scrum and each Agile framework/method/whatever is based on empiricism and experience, we need to know the data.
To sum up, I believe Tom's anger is justified. As most of us talk a lot about adaptation and managing changes, let's use this anger to think for a while, stand aside and have a broader perspective than daily delivery of projects/products. Might be the case that we miss something and we need to adapt. Otherwise we won't be different than the old armies of IT project consultants, telling companies how to do it in waterfall. I hope it is not too late ;)
PS. The data to think about - assuming apps with at least 100k downloads as successful, on Android only less than 6% of all apps are successful*. So there is 94% chance that a product might fail. Plenty of work to be done not to be in those 94% ;)
Sorry forgot to post the source of the data: https://www.appbrain.com/stats/number-of-android-apps
Not for nothing is Tom called the grandfather of Agile. He's kept learning, listening and patiently explaining that badly specified requirements are bugs and the cheapest to fix.
Get agreement with your customer about what they really need and just create that. Tom's cycles (sprints in Scrum) can be as short as a couple of hours.
However EVO and Planguage is not simple to learn; it requires discipline and most customers do not see the point of rigorous, quantifiable measures for their requirements.
I suppose, ironically, you can ask how much along the axis of success they want their development?
I have worked with Tom and applied his methods, as well as practiced Scrum on many projects since around 2006. His insights about software development principles are absolutely spot on. Scrum has failed to deliver on its promises, because it has been taken over by a petty bureaucracy of project managers working to keep themselves relevant and employed over delivering business value. These managers are very good and defending their turf and of course they recognize that Tom's approach to software development shows them to be useless and indeed an impediment to business and technology. So of course they will attack him and try to defend the abomination nowadays masquerading as 'scrum'. Software development will remain in this unhappy state until all these bureaucrats are send packing. They will never leave of their own accord, so the gravy train just keeps on rolling.