Tom Gilb Agile
Teena Ruiter
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.
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.
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!
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.
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.
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 ;)
Best regards
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% ;)
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.
Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.
Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.
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.
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)
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.
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".
c80f0f1006