Some weeks ago, Michael O. Church wrote about his “dislike” about Agile and, especially Scrum. Today, a colleague of mine sent me link to his post, and I’d like to answer him.
Scrum, is a nightmare that I’ve seen actually kill companies.
Michael, it’s pretty explicit, and shows a great distress about your Scrum experience. As I try to demonstrate below, I fell that this bad experience comes from, simply as that, a bad project manager.
Even if this billet d’humeur is well constructed, Michael, it clearly demonstrate a big misunderstanding of what Scrum should be, and agile in general. All you described in your post is contrary to all Scrum spirit. And should not even been called Scrum or agile.
Bad project manager does not need Scrum to tell people they do not work as fast as they should. Scrum helps project manager to give estimate of what can be done in a certain amount of time so other teams (marketing, management) have realistic deadlines. And it’s easier to convince them it’s not possible to go faster with help of graphics and numbers.
A biased definition of “what Agile is”
Michael, you defined Scrum as something humiliating for developers, and that prevent them to work on their duty to appear productive. Indeed, Scrum is based on transparency and communication. Scrum is designed for teams, not for home alone programmers who works for themselves (even if, in my experience, Scrum works very well for one-person projects!). In a team, the lack of communication can only leads to misunderstand and poor-designed features. Reporting, in my experience, is never a waste of time as it can save many hours or days of development.
The fundamental unifying trait [of Scrum] is violent transparency, often one-sided
In great Scrum teams (product owner, Stakeholder and developers included), it’s never one-side transparency. Of course, during development phase, most of the communication comes from the “tech team” (developers and designers), but before that the project definition and the backlog grooming are times for Stakeholder and product owners to be transparent. They share their feelings, their needs. They share why they can’t spare a feature and learn when it’s not possible to deliver on their own agenda.
After a while, non-tech teams learn that when one feature cannot be delivered in time, there is a reason. It’s not just that developers are lazy (which, before Scrum, they would have probably believe).
Poor Scrum master, leads to poor product and to poor work life
The transparency should not be violent. In Scrum, as for any part of the life, respect and failure tolerance (to fail is to learn) are signs of great teams. The Scrum Master is not only the task manager. It’s his duty to make the life of all parts as easy as possible; to extract the best of every team member.
Each person’s hour-by-hour fluctuations are globally visible– and for no good reason
On the contrary Michael, there is no such things as hourly commitment in Scrum project, because the development team commit to deliver user stories within a Sprint. Not on a specific day or hour. In my experience as developer and project manager it is most comfortable to not have pressure on daily basis “Is this task done? And this one? And this one?” This is why estimate use abstract items.
There is no “one person failure”. The beauty of Scrum is that, if the project fails, it’s everybody’s fault, so it’s no one. The developers failed to deliver because the product owner failed to give a good requirement list, a good definition of satisfaction, because the stakeholder failed to give a simple yet complete vision of his request and the product owner failed to detect it and the developer failed to foreseen the whole and of course, the Scrum master failed to catch the missing parts. There is no one to blame except maybe the Scrum master itself.
Because of concepts like daily Scrum, every part of the team have a clear view on what and who is doing what. Missing, misunderstood are discovered fast enough. If, of course, the team communicates.
Developers should be interchangeable
Michael, next, you complain that agile treats programmers as interchangeable. And it’s a very, very good point. You should be very glad if you achieve that, because it means that workflow is consistent, and that, in a business point of view, you’re not bond to one specific person. In case one programmer only could work on one part of a project, would mean that, in case this guy is leaving the company, the product is dead, no one able to update it or finish it.
And from the programmer’s point of view, it could be very stressful to work in other way (on the condition that the programmer has a professional conscience). Knowing that I can’t be sick or take vacation without pausing the project, puts a lot of pressure.
For people with anxiety or mood disorders, […] who tend to be most sensitive to invasions of privacy, this is outright discriminatory
I’m sorry, but I can’t accept this argument! The productivity, or project tracking cannot be “privacy”! You are paid for a work, you work in a team and people wait for your work to continue theirs.
Business-driven engineering
I’ll pass on your two paragraphs about “Waterfall” on which I quite agree to go straight to the hierarchy part. You write that agile (while describing Scrum roles) does not have a “well-defined hierarchy”. Once again, I disagree with you because the hierarchy is pretty clear. The stockholder define its needs. The product owner choose, business centric, what should be done or not and the development team has full authority on how it will be done and when.
With Scrum, you can’t have a product owner saying “I want that for the end of the month.” No, it’s to the tech team to define what can be done for each sprint, and in what order. As it is well-defined, the product owner has no way to tell the tech team to prioritize one task on another within the time of the deadline. Sprint goals are defined, and tasks are ordered by the tech team.
The “product owners” and “Scrum masters” outrank “team members”, who are the lowest of the low.
Wrong statement. Each part has authority onto its own domain, to reach the same goal. Once again, it’s the duty of the Scrum master that these principles are respected by each parts.
Then you state that reporting process should be juniors’ tasks. I’m afraid I’ll have to disagree once more. At every level, reporting help the programmer. First, to be sure that she/he has done what she/he committed into. And second, to be sure that the feature she/he is delivering matches the request.
In Scrum, programmers doesn’t “work only on [their] assigned tickets”. This is what daily Scrum are for. Daily exchanges with everyone to identify difficulties. And for those in difficulty, to ask for help and to get it from anyone in the team. Because everybody talks during meetings, everybody has his chance. No newbie is left aside because ashamed of speaking to pgm.
Agile increases the feedback frequency while giving engineers no real power
At any time in the project, especially during daily Scrum, any programmer can convince and argue to delay a story or stop it. In most case, against product owner or stockholder, the programmer has support from the rest of the tech team, who understand the problematic (or can help to find ways to resolve it).
Silicon Valley has gotten a lot wrong, especially in the past five years, but one of the things that it got right is the concept of the engineer-driven company. It’s not always the best for engineers to drive the entire company, but when engineers run engineering and set priorities, everyone wins: engineers are happier with the work they’re assigned (or, better yet, self-assigning) and the business is getting a much higher quality of engineering.
I hope you’ll be glad to read that, this time, I strongly agree with you. But eventually, these engineers stopped to be engineers and became product owners.
Terminal juniority
Michael, let’s be back to our disagreement now, or this post will have no means. Agile does not have exit strategy because it doesn’t need to. R&D, improvement and refactoring can easily be Scrummed (or sprinted). In R&D especially, I can’t see any valid task requiring more than two weeks. It would be unmanageable. On the contrary, sprints force you to split your work to fit in. Let’s say you want to find a way to improve the response time of your API. Indeed, if you write your user story like this, it certainly won’t fit. But then, you have to think about it beforehand, and split it per example, by route. Then, improving a route, can fit in a two-week (or so) sprint, among stories from other projects. The epic “improve the response time” has no great business value because the API works well already, but is a long term goal.
Good practice is to make bug fixing and technical debt visible.
I’m currently reckoning of adding a “refactoring” part for each of my projects from now. And it 100% compatible with Scrum multi-projects.
What “Agile” and Scrum say to me is that older, senior programmers are viewed as so inessential that they can be ignored
Seniors are essential in every projects, Scrum or not. I’m not far from your age and I’m pleased to work with programmer 10 years younger than me to 10 years older than me. Everyone was very kind to test Scrum and, as far I as know found it useful. There is real pleasure to check task after task and see the burning chart going down day after day. And if a line stay flat for a while, we don’t have to wait for the programmer to ask for help, but we can go and propose help.
This is the role of the Scrum master to highlight this.
Scrum does not consider experience as inessential. Bad project manager does. Maybe your team does, I can’t agree more with you; it’s bad behavior!
Dangerously short-term
Within the last two years, before getting my team into Scrum, I was lucky enough to get a pretty good view at it from different roles.
First, I had inner feedback from one the biggest worldwide tech company which does agile and Scrum for long. Then, inner feedback from one of the three top (if not the top-top) bank company of France which implement Scrum (from a not-at-all agile methodology).
After many months of almost daily feedback from a friend of mine there, I’ve decided to give it a try. First for a project on which I worked alone. And, as I found it so wonderful, I’ve evangelized the rest of the company. Even marketers (our product owners) who were reluctant, now are very fond of our daily Scrums and backlog grooming.
Then, I recently had experience to work as Stakeholder with one other big firm (tech) and the experience was nice. It felt good to have regular updates and mostly, on a few months project, to have a clear view at any time on where we were in the project, what’s left, what’s done.
I do not work in a big company (but I’ve seen result), nor a startup. My company is a “regular” but dynamic company, with brave enough people at the head.
individual engineers are rewarded or punished solely based on the completion, or not, of the current two-week “sprint”, meaning that no one looks out five “sprints” ahead. Agile is just one mindless, near-sighted “sprint” after another: no progress, no improvement, just ticket after ticket
This only denotes once more the poor project manager you have/had. This is not linked to Scrum or agile. Not at all because as I’ve already said, all of this descriptions is contrary to all Scrum spirit.
Career coherency
By age 30, you’re expected to be able to show that you can work at the whole-project level, and that you’re at least ready to go beyond such a level into infrastructure, architecture, research, or leadership.
All of this can, and should be part of a Scrum project. It seems to me that in your current position, you’re desperate to get responsibilities, and project influence. It’s very nice and I encourage you. Scrum is not your enemy here.
Infrastructure, architecture and research are part of the backlog. Leadership is not part of it, but Scrum give you many opportunities to gain the leadership not by your job title or age, but by the acknowledgment of your knowledge.
Its purpose is to identify low performers performance
Only really bad Scrum Masters will sack so called poor performers. While Scrum allow to identify impediments, it does not allow to sack a specific person, because all user stories are different, it should not be easy to blame one person for not closing a user story. And if you can, then, I really think it’s because the programmer is really, a poor programmer, and such person should be removed from a team to find another job. Kenneth S. Rubin (twitter) in his amazing book “Essential Scrum” (which I can only recommend) states that “individual velocity should never be use as individual evaluation”.
Velocity estimation is certainly very imprecise during first iteration, or for a new team member, but this has to be considered by the Scrum master. And after a while, a bad estimate will means problems in the story definition. The Scrum master focus on the team work. Team members focus on each others. Programmers can judge their pair.
The obsession with short-term “iterations” or sprints means that there’s no room to try something that might actually fail.
On the contrary, Michael, like in any project management, it’s up to you, as programmer or project manager, to keep user stories dedicated to R&D.
Focus on idle work, not idle workers […] “Watch the baton, not the runners”.
If your project manager is not kind to add such user stories in the backlog, then it would have been the same in a non-Scrum project.
The truth about underperformers is that you don’t need “Agile” to find out who they are. People know who they are. The reason some teams get loaded down with disengaged, incompetent, or toxic people is that no one does anything about them. That’s a people-level management problem, not a workflow-level process problem.
As I’ve said above! Totally agree.
“Scrum” was a term sometimes used for what corporations might also call a “Code Red” or a “War Room emergency”
I’m afraid I’ll have to contradict you there, as Scrum is a term used in rugby (link) and is not so much about crisis (even if I agree it can have been used for that too), but originally for:
Players packing closely together with their heads down and attempting to gain possession of the ball
Go fast but never hurry […] Hurrying will likely come at the cost of quality.
In Scrum, quality […] is something that a cross-functional Scrum team owns and continuously builds.
This makes all your following statements, like “Scrum glorify emergency”, invalid. In my experience, it’s much easier to individual to manage their time and their development in a scrum environment.
Conclusion
I’m really deeply sorry to read your experience with Scrum, but I’m convinced that it’s a bad experience as you have bad management above you. They failed. Not you. And not Scrum. Scrum is not for every team, as you said, it’s a commitment from every members. You can’t not-be-agile among a Scrum team.
But when everyone is in, it’s a dream!
Answer to article from Michael O. Church:
Why “Agile” and especially Scrum are terrible
Essential Scrum on Amazon, by Kenneth S. Rubin
Featured image from http://www.axisagile.com.au/resources/Scrumtrooper-images