Street Cred
I’ve been in the software development industry for 21 years, using agile software development practices and principles for 14 years to actually deliver software. I’ve been working with Scrum for nigh on 11 years now and over the last 7 years I’ve coached over 120 teams and worked with over 1200 people.
With all this experience one thing has become clear – Scrum is broken.
How I assess the quality of any agile process
In theory, it seems all neat and tidy, but in practice it is abused, misused and generally ineffective. And I wonder why? I have seen many more poor implementations of the Scrum framework than successful ones. Actually – let me be explicit about how I assess the quality of implemented Scrum.
For me the success of *any* organisation’s way of working – formal or otherwise – can be checked by simple questions that explore 5 fundamental concepts:
- Value: Do we know the value we seek to deliver and are we consistently delivering the maximum value?
- Flow: Do we understand how we reach that value and are we consistently reducing the time and/or increasing the ease by which we reach it?
- Quality: Do we understand how good our product and workmanship needs to be and are we consistently and demonstrably achieving it?
- Joy: Do we know what we collectively and individually need to be joyful and are we consistently meeting those needs?
- Continuous Improvement: Do we know what we need to improve across VFQJ and are we demonstrably pursuing those improvements?
This simple list of questions invites great questions and other avenues of inquiry. It can function as both binary (yes/no) and range (how well are we doing). Works for me – mostly.
The non-recipe recipe
The fundamental reason why Scrum – as it currently exists – is broken is that it is a set of instructions, roles, rituals and artifacts that purports to *not* be a recipe. But almost every one takes it as a recipe and they follow it. But there is not enough there to be a an all encompassing recipe – there can never be.
The trouble is that, as a product , Scrum needs these illusions of completeness in order that it is taken seriously . By and large this has worked. In a world that is seeking silver bullets, Scrum has succeeded beyond it’s practicality commands. It is by far the leading agile process framework in use today. It is in this illusion of completeness that lies the myriad of problems.
I remember in 2008 or 2009, there was a statement about there never being ‘Scrum 2.0’ – that Scrum was complete as it is. A perfectly chiseled gem that needed nothing removed nor added. This was clearly bollocks and persisted until politics and greed spilled over in the Scrum Alliance causing a bitter split between one of the co-creators of Scrum and the rest of the Alliance. All of a sudden a Scrum 2.0 in emerged in all but name.
When people have applied Scrum as a recipe the commentary from the unsympathetic dogmatics has been of the nature of:
“ScrumBut”
“Scrum shines a light on where you need to fix in your organisation”
“Scrum works, you just did it badly”
“You didn’t have buy in”
Overwhelmingly any reasonable objection to some of the design flaws – and design flaws can emerge after the fact , exposed because of a change of operating environment etc – is often met with “those people are resistant, they are against change”.
When Things Work, Its the Process – When They Don’t, It’s The People
I was first attracted to Scrum because I believed it would revolutionise the ‘world of work’.
10 years on and I’m deeply disappointed. It did not revolutionise the world of work. Instead it got gobbled up by the Death Star of Work. If it had any early promise – for me it was that it would promote unprecedented collaboration between the people focused on delivering value and the people consuming it.
It may have had some success in some organisations – but this is far from ‘changing the world of work’. A tiny street maybe, but never a world!
Of course a process doesn’t do anything – people do. But how a process is designed has a huge impact on how readily the people take to it and how easily they can use it for the intended purpose.
More often than not I see a growing perception of infallibility of a process and an overwhelming blaming of the teams and individuals who play the Scrum roles. I feel deeply sad and angry at this.
Multiple single points of failure
Scrum Master, Product Owner and Team all collaborating beautifully – each with its clear role and responsibility – what’s not to love?
Except that in *most* companies roles are so entrenched and siloed that this is the worst thing you could do – add more roles that become siloed. I hear you scream – “yes but the problem is the organisation and not Scrum” – and you are both right and wrong.
You are right because it is the organisation that is siloed and you are wrong because adding more roles when you *know* that most organisations are siloed is a dumb idea. That is like asking the morbidly obese to incorporate 3 more meals – however small – into their already dangerous diet.
Defined roles and a culture of collaboration are difficult bedfellows in any context. Especially in the context of trying to explore value through . Defined roles present an extra hurdle to overcome as we truly try and work together.
I have seen product development be disastrous for many reasons and the most common one is the single point of failure problem. Examples abound:
- Overworked, overextended and ineffective Product Owners;
- Scrum Masters left to single-handedly be responsible for improvement and impediments and latterly ‘coaching’ the team.
- Teams that aren’t to effectively own their tools, their craft or their collaboration.
Rituals become checklists vs achieved outcomes.
If I have to walk into another planning meeting that is schedul for 4 hours because Scrum said so – with the hope that somehow the information we don’t have about the work we are expected to commit to will magically appear – I may have to shoot some unicorns.
Sprint after sprint, people do the meetings, the stand ups, the reviews etc. Scrum Masters – bless ’em – scour the communities for how to make their standups more interesting. Velocity is going up, teams are 7±2 people – things in the product backlog read like ‘As a …, I want…”. The process seems to be working perfectly.
Yet software is still sitting on the shelf. Customers are not getting anything to feedback on. Developers still don’t talk to customers.
Velocity becomes a stick to beat teams up
So velocity is not a defined part of Scrum – but it is a defacto part of Scrum implementations and it is both a arbitrary and crude measure of something.
Velocity doesn’t mean what you think it means. It is about capacity,not speed It is *always* historic and never comparable to any other team and barely comparable to the same team over time. Sure it is a number and numbers can be compared – and that in itself is a problem because the human factors that help that number pop out are deeply flawed in most organisations.
Thankfully, the #NoEstimates movement is bringing some well deserved improvement in thinking in this whole area.
Of course you need a measure to know how you’re doing. But velocity is a poor one. The emergent product and how well it is meeting the needs it was intended to meet is the ultimate measure – sadly many organisations are unable to get this – so they overdose on the measure that came with the process.
So narrow as to be quickly redundant
I was in the market for car seat a few years ago and was faced with buying something that was super specific for my son at his then age – he was 3 years old – or buying something that would support him till he was 8 years old.
Guess which I bought.
Scrum purports to be for ‘new product’ development – and I wholeheartedly agree. Except I don’t know *any* teams that only do ‘new product development’.
Even if a team that started out with only new product development – after their product reached its first users – their work mix would need to change. The fixes, bugs and so on that are different classes of work and different service responses change the mix. You could use Scrum to do these classes of work – but that would be akin to picking your teeth with a vacuum cleaner.
And this is just product related work – but what about the work everyone needs to do to continue to improve? The Human Development work? How about using Scrum for that?
If Scrum was the only thing you did – and many organisations adopt it as such – then it would get misused pretty quickly because getting shit done always trumps following a process. The question is how much of a hatchet job do we have to do to the process to get the shit done.
Scrum Shows You What Needs Fixing, It Doesn’t Fix Them For You
If I had a penny for every time I’ve heard this, I would be rather rich.
Of course Scrum should fix something – everyone I have ever met in a company *know* what is wrong. They don’t need a fancy methodology to tell them what is broken. They need something to help to try and address the problems and Scrum does not not address any of those.
If the problem that Scrum fixes is exposure of problems then it needs to be pitched as ‘a framework for exposing what is preventing you from doing joyful, fulfilling new product development work’.
It ain’t all bad.
I don’t hate Scrum – I’ve just use it long and deep enough to understand which bits I would throw away and which I would keep, what contexts I would use it in and which I would bury it so deep – no one would ever find it.
If you are using Scrum – I beg you to question it all. Ask yourself, your team, organisation and customers whether this is really helping you and what you are really trying to achieve. Don’t even mention Scrum during that conversation – simply talk about ‘how are we delivering what we seek to deliver” .
As with most things, all this can boil down to simple choices.
Do you choose to blindly follow a process or do you choose to adapt your own way of working that is focused on value and joy?
Good luck whichever you choose.
Excellent.
Part of what you describe is the result of Scrum being “a product.” Selling a product – a ready made solution to your problems – is far easier than selling a bespoke solution to what ever problems some one has.
The good news is that product Scrum has reached places other methods – XP, DSDM, FDD, ASD, etc. – can’t reach. And the better news is that it has done some good, made things better.
The bad news is that sometimes the buyers mistake the Scrum Product for the product they should be producing (thus stick to it too rigidly) or decide that Scrum must be adapted to their environment (and dilute the bits that will help.)
I’ll take slight issue with you over Value, Flow, Quality, Joy and Continuous improvement. It very easy for you, me and many other Agile-ists to say “these are the things we should be improving” and “you aren’t there yet” but in doing so we are imposing our beliefs on the way things should be. It is entirely acceptable for a company not to care about joy, and if they don’t understand the role of quality why would they consider that important? As for value, its hard, far easier to look at cost so why blame people and organizations?
Just because you and I can see how much better V-F-Q-J-CI could be doesn’t mean we are right to judge others by our standards when they judge themselves by others.
Thus, for many Scrum buyers what Scrum delivers is better, better than what went before by some (probably undefined) criteria. It may look bad to us but what gives us the right to say they are wrong?
I also know, having offered my own “Xanpan” to the world: that the same fate probably awaits Xanpan. No matter how much I say “Roll your own” some part of Xanpan will be taken as a false objective.
Hi Allan
Thanks for engaging on this post – I want us (everyone involved in this work) to talk about these things and apply what we learn into the work.
I agree on the good news – it has gone farther into places than anything else – possibly combined! And it has moved some 800-pound gorillas a few millimeters – more than they could have hoped for.
My intention was not to portray V-F-Q-J-CI as the only way – simply as my own way of assessing when folk say we are doing ‘X’. Not sure to what extent it is imposed or a passing of judgement of ‘right or ‘wrong’. Funny about your comment on companies not caring about Joy – it reminded me of the one guy who threw his hands up in frustration and shouted ‘You’re having a f%cking laugh’ when I suggested that Joy was an integral part of effective human work!
My key point is not to bash Scrum, it is that with the benefit of so much circumstantial data on how Scrum is misused – for its owners to critically look into how this data can be applied to its evolving design. It is what teams are asked to do after all.
Misused or misunderstood? – If there is misuse I prefer to think it is unintentional then deliberate, and I’d guess you agree.
Some of what we are seeing is another set of tensions. Agile, Scrum, etc. can fix a lot of problems. You, me, and a bunch of other people can see how to fix many of the more common problems.
But when you fix them another set emerges. Maybe not so much problems as forces which have yet to be resolved.
#NoEstimates and #NoProjects are both a response to how we see the world now one set of issues has been solved, mis-solved and some other problems are apparent.
Yes – there is a question that can be asked – misused or misunderstood. Personally I think the outcome remains unchanged and the main point is still relevant in both cases.
What is it about Scrum that leads it to be so widely misused OR misunderstood?
I also agree with the emergence of new problems – at the same time, there is often emergence of new opportunity too. So it is part of the territory.
Re: #NoEstimates and #NoProjects – I’m not so sure. As far back as 2002, I can remember individuals pushing back on both. Maybe now there is an increasing groundswell around both – but none of the reasons I am hearing are anything new. They are simply more popular – and perhaps more accessible. Potentially more achievable in the mainstream too.
A pleasure as always Allan.
Mike, I disagree with you on most of your arguments you put forth. And boy, don’t even know where to begin to present fundamental flaws in your arguments.
The reason Scrum is hard to implement is just one – because it is so simple!
People are used to “heavy weight” processes and methodologies and Scrum to the contrary is refreshingly simple, straight forward and lightweight. Many orgs end up putting their own “heavy layers” of BS processes on top of Scrum.
The second reason Scrum is practiced so badly, is that orgs are not investing time and effort in either hiring experience Scrum Masters (SM) or building this capability in house in their existing employees.
Third, Product Owners are not allowed to operate as true Product Owners. So in addition to their regular job responsibilities, orgs are asking folks to also play the role of PO. And these newly appointed POs do not do justice to their role because they just don’t have the time!
Last counter argument is that Scrum is new; its only been around for less than 15 years. Any new process or methodology takes time to take root be practice well. Also, the other existing processes and systems in an org will take time to adjust (and they are adjusting, it is clearly visible if you look carefully) to the new (Scrum) process which is rocking the boat, in some instances slowly, in others more forcefully.
My prediction is that we will not see the widespread “healthy” practices of Scrum until perhaps another 10 years.
Finally, waterfall has been around for close to 50 years, or more, it is still practiced poorly, yet is still in widespread use. So… should I say more.
Manjit – thank you for your comment. Disagreements are welcome when they are non-personal, move the discussion forward and respectful. I’m pleased that yours are all three!
I also cannot begin to counter the fundamental flaws in your counter-arguments. But I’ll try 😉
Why do companies put their own layers of BS on Scrum? If you design your product (in this case Scrum) only able to play well with some other products – why not say what their characteristics are. Scrum is often pitched as ‘medicine’ for malfunctioning companies. *All* medicines tell you what you should definitely not take them with – like Aspirin and other blood thinning medication.
Hiring experienced Scrum Masters – what does that even mean? Experience of what exactly? The WORST experience you can buy is those who come an a Scrum recipe to every situation. And why is this silo’d into the Scrum Master? In the end the experience anyone has in this area is of the nature of vague patterns, their real value and ‘expertise’ is that they know how to how to think about what those patterns might mean and how they might react.
I am in deep disagreement with your point about how long Scrum has been around and the impact on how people are using it. The interest in Scrum is huge – lots of people in many different contexts are using it. If we consider it a search, we have hundreds of thousands of people searching for the golden needle of ‘good scrum’ in the haystack, from different angles and using different approaches. It matters much less how long it has been around for and more what those experiences are showing. Should we not take that data and apply it to Scrum itself? Are we not more likely to get the future that you speak of where more companies are getting what they want through Scrum?
In the end – the crumbling of Scrum has started. The refusal to consider this evolutionary design is creating competitors who are taking that learning and applying it into new methodology products (SAFe, LeSS are examples).
As a mentor of mine once kindly shared with me – “Be careful what you predict”.
Scrum will be forgotten like a fluke of evil will, ever twist of follow my puppets and don’t pay attention to the man behind the curtain. Instead a brand new and shining miracle pill and tree of youth will descend upon us and millions of new consultants will swarm and feed, and incite young minds that a happy developer future awaits them. And yes, these consultants would immediately dismiss my words and the young minds would refuse to believe.
So very true. Every group I’ve ever seen that embraces (not just adopts) ALL the principles of Scrum finds themselves achieving more than any of them had ever imagined possible. Everyone else does the ‘lipstick on a pig’ syndrome and they get commensurate results. I suspect those who argue to the contrary are those who are running around with their proverbial tubes of lipstick desperately afraid someone will discover their blaming of others and the process is just a cover to hide their own inadequacies.
Great article Mike, and lots to agree with in there from my point of view.
Having worked with Scrum for a very long time (CSM since ’06) I have to concur. We very happily abandoned Scrum and all of its foibles a couple of years ago (incidentally with some good involvement from Mr. Kelly who is sitting a little further up this thread) and have largely moved to a kanban(ish) system now – and I highlight the “ish” bit as one of the key things we learned was that without bending it to your own needs any ‘system’ is bound to fail.
We’ve still got the Scrum roles broadly, and having a Product Owner representing the Product in the team is massively valuable to us but we have abandoned the things that caused us the most grief which were the fixed dates, the horrendous planning sessions, and the deadly burn-down.
Getting rid of fixed iterations was by far the strongest thing we did. We used to run two week sprints which broke down roughly like this :
Days 1 and 2 : Fixing the stuff we had hacked to make it look like it all worked in the last review.
Days 3 and 4 : Planning. Sitting in a room *determined* to plan every last detail of the next two week’s work. Three people talking all the time, three people sitting quietly in the corner, two people rocking slowly back and forth contemplating suicide.
Days 5 to 8 : Yay !! Coding, testing, working, producing good stuff, doing what we were employed for. WOO !! However, we did need to also work out a way to crow-bar defects through the system when they weren’t actually attached to a story, and they weren’t new work . . . they just didn’t fit – perhaps we could have a bug-fix Sprint next time, maybe we should exclude them from the burn-down as they aren’t new work, perhaps we could just fix them in over-time etc etc ?
Day 9 : Start hacking unfinished stuff to make it look good for the review.
Day 10 : Finish the uncomfortable hacking, arrange the mirrors, start the smoke machines. Review at 2PM. By 4PM everyone feels down that they haven’t been able to focus on actually getting good stuff done, but hey, it’s the weekend now, byeeeeeeeee.
Then rinse and repeat with a constant background of noise from management’s morbid interest in the shape of the graph and the particular curve of the burn-down chart and exactly when that line was going to get steeper.
Now, I am explicitly and very loudly *NOT* blaming Scrum for this any more than I blame geography when I can’t find my car keys, but the framework/process gave us an excuse to focus on the wrong things and it really helped us to fool ourselves that we were being successful because we were following the process well even though we weren’t producing any product.
So, time for a change !
We stopped the heavy ceremonies there and then.
We worked very strictly on our WIP limits and got stuff *finished* before touching the next card.
We binned the magically collaborative electronic super-Scrum boards and wrote a whole load of cards to put on a whiteboard (or five).
We banned “big-room” planning sessions and replaced them with short “story kick-off” meetings as required.
We delivered value when we could, and we called a review when we had good stuff to show, not when the calendar said we should.
The numbers we used in estimating got more and more vague and abstract in an effort to wean management off them and then we just stopped estimating completely.
We ensured that the best stuff (and by best I mean “most valuable”) was at the top of the list and we worked down it and every now and again we asked anyone we could to let us know how they thought we were doing.
And we’re still doing that. And quality is up, productivity is up, and we are seen by the rest of the business as one of the teams to be trusted who “gets stuff done”. We say what we’re going to do, and we do it. I dare say that we could have gone back to the drawing board and done Scrum “better” but I think we needed to stand on our own feet away from the crutch of process.
And on a personal note, I never renewed any of my Scrum credentials this year so I am no longer entitled to pay to put some little blue logos near my email signature and having been a book thumping advocate for a long time I gotta say that it feels kinda good to be naked !
Mic – I love love love this comment – thank you. If there was a new ‘From the Trenches’ this deserves to be in it. Not only because it agrees with my general opinion (clearly I’m biased – but it’s my blog and I can cry if I want to!).
I get the sense that you guys realised it is your process and it doesnt have to be called by any name.
Congratulations on breaking free of the certification trap – I broke that 4 years ago and never looked back. It makes me giggle me when I see people with certification acronyms after their name that are longer than their name. It says to me “I’m great at examinations and following prescribed instructions” than “I know what I’m doing”.
Keep doing great work and thanks for sharing.
Mike … I wish we could sit down somewhere and talk. Come to Brighton sometimes and we’ll do it. My Brighton, though, not yours. 🙂
Of course I agree that all the abuses and misuses mentioned here really do commonly happen. And I think we would agree that Scrum doesn’t ask for any of them, and often even contains specific advice that, if followed, would prevent them.
My doctor gives me very good advice. He told me an easy to follow diet, and recommended aerobic exercise at least three days a week. I eat whatever I want, which is mostly donuts and cookies, and I exercise by walking from the closest parking place to the coffee shop and back. I do not blame the doctor, nor “Medicine” for that. I know who owns this failure.
So I’m left with two problems here.
First, I don’t see how it’s reasonable to say “Scrum is Designed for Misuse” unless it’s also fair to say that Medicine is designed for misuse. I think people misuse good advice, in what seems some days to be almost every instance. I don’t see how it’s useful — or even true — to say “Diet and Exercise are designed for misuse, because I didn’t diet, and I didn’t exercise, and I didn’t lose weight”. And I don’t see how it’s useful — or even true — when you say Scrum is designed for misuse because people don’t do it and don’t thrive.
Now I did notice that you had an example or two that are about following Scrum, like religiously holding a 4 hour meeting “because Scrum says”, but even there we know that Scrum really says that the (empowered) Product Owner presents things that are to be done, and the team selects how many they can do and figures out how to do them. If an unprepared PO shows up, they cannot present, and the team cannot figure out, and the Sprint Planning meeting cannot finish in the time box. And you’re supposed to “inspect and adapt” until you’re doing it well enough.
So even there, it seems to me, it’s clear that those people are not doing what Scrum people advise. So I do not see how it’s reasonable to blame a framework that is not being used for what happens.
My second concern is this: Consider the kind of organization that “buys into” Scrum. They have problems, they know they have problems, and they want to fix them. What are they to “buy into”? Now, sure, they can call you or me or these other 14 people we know and those people will work with them for ages and help them get truly “Agile”. But no. We 14 cannot serve those organizations. There are too many of those organizations, and too few of us.
So what’s the alternative? Offhand, I can think of no process that cannot be misused, and no process that, in particular, would work for the company where Scrum does not work. What can we give to those companies that will work better than Scrum? What can they get “in a book” or “in a few days of training” or “not very expensively” that is better advice?
My guess is that there isn’t anything we can offer, in the form they “buy” things, that is better advice.
So, fine, we could say “sorry, I have no advice for any company I can’t visit”, or something of the like. Maybe that’s the thing to do.
Except for two sub-items: 2a, companies taking up Scrum do seem to get some benefit, so offering them nothing is actually worse. 2b, in the absence of Scrum, they’ll take some advice that’s even worse.
Thus I’m left disappointed when I read an article like this one. It mentions a real situation which is bad. It attributes the problem to something external to the company and which therefore cannot be solved. And it offers no alternative that would be better.
What am I missing? Am I wrong to want to focus the company’s attention on itself, not on some named method that it isn’t even following? Am I wrong to want some actual actionable advice for that company?
Kindest regards,
R
Hi Ron – this topic continues to run and run! Perhaps we should do a talk on it together.
So if Scrum is designed for misuse depends on ‘medicines designed for misuse’ to be true. Then Yes – medicines can be designed for misuse. For example, the dosage of Parecetamol you can buy in Spain is 1 gram. Take 8 of those and you might drift peacefully away someplace with optional intestinal bleeding. And the blister pack has 60!
The key point here is that misuse emerges over time. Drugs can be misused and when they are, they are either regulated (which can be considered a part of the design) or chemically modified (like mehtylated spirit) – to deter abuse.
Of course it is users who misuse – and the cry from dogmatics is ‘blame the user’. I think you and I are in agreement that this is rarely productive. As you say, these are people who are seeking some benefit. I don’t agree that *everyone* knows what their problem is. I do agree that there are outcomes that people desire and that is what they think they are trying to attain by ‘adopting’ Scrum.
Following the post on your blog, I have added a task on my list to write my thoughts on alternatives and conditions that I believe need to be satisfied before anyone in any organization should ‘do Scrum’. Of course these are not enforceable. Or are they. I still don’t have time or head space to really get into that post, but I will – someday 🙂
As for alternatives – I actually believe *any* process that a group have a voice in choosing and feel personally committed to improve would work better than Scrum (or any other process that is imposed). My view is that it doesn’t matter where you start – it matters more that you chose how to start and are committed and permitted to change it to as you need.
I don’t hate Scrum – I hate that it has become something used to hurt people. It is often used rigidly but it lends itself to rigid use because it has defined roles and responsibilities. If you didn’t have defined roles and responsibilities – of course chaos and confusion can occur. I have proved in my engagements with clients that you can overcome this chaos and confusion with transparency and clarity of the goal – a kind of Commander’s Intent. No roles, no silos, no blame.
My argument is not the other extreme – that users aren’t to ‘blame’ and it is all on the tool or the designers of the tool. That would be as dumb and as unbalanced as saying it is always the organization or the teams that didn’t use Scrum as intended. I observe so much of this from people who really should know better. It is a form of violence IMHO – to which I cannot subscribe.
Like the 1 gram Paracetamol that comes 60 in a pack (when 8 or 12 could kill or seriously hurt) – there is a design flaw to the user experience.The solution is to address both.
So – no, you are not wrong to focus the company’s attention on itself – that is what I also want to do. And I find having Scrum as a tool is – currently – less helpful in that objective. You can have actual actionable advice for that company that doesn’t have to be ‘go do Scrum better’.
As always – with deepest regard.
Mike.
Hi again, Mike,
As to the “blame” issue, I’m not about blame, but I am about personal responsibility. Not that I’m terribly “responsible”, but that I simply cannot accept that the world controls my life without any ability on my part to control it. I like to have the illusion — and I know it is in large part an illusion — that I’m more or less in control of my life. I’m happier when I do things to make my life better.
And I’m one of those people who thinks everyone in the world is like he is, so I think that everyone would be better off taking more control over their lives. I really do think that.
So when it comes to Oppressive Agile, as I’m calling it today, I feel badly when people just sit there and take it. I feel that developers have great power, based on the XP-style technical skills, which give them the ability to show real, running, integrated, tested software, every couple of weeks. That can be a great influencer.
To use that influence, however, requires some skills and practices that we haven’t talked about much in Scrum/Agile. Working together as a team, you have to show your work, be prepared to explain why you’re already going as fast as you can, and so on. We’ve not given as much guidance on how to do that as we might have.
Be that as it may, however, I do believe that if a team is Oppressed, or just not experiencing much Joy, it is primarily their responsibility to improve the situation, not the responsibility of Scrum or some teacher of Scrum.
Some people, who have not taken that responsibility, or have not succeeded with it, choose to blame Scrum. Frankly, that’s just not on. They’re the people on the ground. They own the problem and need to own the solution.
I think we need to help them own the solution, and I think that blaming Scrum disempowers them when they need empowering the most.
I remain, yours in our common quest, etc etc, with kindest regards etc etc. 🙂
R
This was a very interesting thread of ideas. After reading all this I wonder if you all are considering that for any “diet system” to be effective most of the time it should be built to account for human failure? Not planning on that is not realistic, and so any system or framework that take certain human failures or realities into account is by definition in-complete, or not always appropriate.
If an economic system were purported to be perfect, and guaranteed to provide prosperity to a nation then it would be blindly followed. Well, there is no economic system designed that can take human behavior completely into account – and since you can’t predict it then you can’t guarantee the outcome.
It seems to me that since everyone is right in their points that the best approach is the following: If it ain’t broke too much, maybe don’t fix it. But if it is broke and you know it, then do fix it – regardless of your system.
Patrick – some really interesting comment and caused me to think deeply about this thread. Thank you.
No system is ever perfect or at least not permanently. Needs change, capabilities change.
Without inspection there is no adaptation – so if change is inevitable and can lead to positive and negative outcomes – the least we can do is pay attention and develop tools and disciplines to inspect deeply and truthfully.
Scrum is a starting point for many teams – and at this point, I don’t really care where people start, so long as they do AND commit to inspecting and adapting as it suits them in that time.
The consultancy market has created a problem that is threatening to kill this very simple idea that is represented by the Manifesto for Agile Software Development.
Love this post and all the replies. I wish I could find joy again … Scrum being forcibly implemented in my company has robbed me of it completely. I don’t want to go back to waterfall, I believe in agile delivery to customers, I was doing it myself for 2 years without a formal methodology … mine was Get $hit Done Right & as fast as possible. I had very happy customers & top performance ratings. Mic Streeter’s comments describe exactly what I wish I could change.
(A comment on an old article, but I just came across it from the Ron Jeffries site.)
“Scrum shines a light on where you need to fix in your organisation”
Random story this brought up: About 10 years ago, I got talking to my then boss about Scrum. He knew that I’d become a CSM some years before (That was 2002? Maybe it was before the manifesto? Anyway, it was at OOPSLA and the only person teaching Scrum at the time was Ken S.)
I was describing Scrum. And I said that if there was a need to completely change the direction of development, the thing to do was to abort the sprint, re-plan and start over. My boss and I looked at each other for a minute, realized that there was no way the owner of the company could keep to one direction for two weeks at a time, and there was no question of even attempting to implement Scrum.
It’s not a flaw in Scrum that this company was so screwed up we could tell Scrum wouldn’t be possible there.
On the other hand, I can easily imagine a highly-paid Agile consultant coming in with a line like “twice the productivity in half the time”.