What's wrong with Agile these days? You are.

At the risk of sounding like a Scrum purist... I must speak out.

We barely had time to blink and here we are already: for all the talk of replacing the rigid, old-fashioned, inefficient, wasteful — insert a damning adjective here — Waterfall-based development lifecycles, we might think we have succeeded: experience with Agile methodologies, familiarity with Scrum and its ceremonies, ability to work in self-organizing teams are ubiquitous requirements in every job posting nowadays — or do you dare send a CV or update your profile to claim you've mastered the art of Waterfall, and do you think that will land you a job? We now have tribes, squads, chapters, a plethora of nouns to describe highly efficient, unorthodox teams, and we have all somehow done (!) the "DevOps transformation", enabling us to deploy fifteen times a day if we want (as that's what influential books claim is the sign of success for software companies).

Still there's trouble in paradise. Why do we hear everywhere (legitimate) critique about "how suspiciously waterfall-ish our processes are"? Why do devs absolutely loathe, mock and make no effort to learn anything about Scrum? Why are project managers, delivery managers, heads of product and Tribe leaders working excruciating hours to make sure products materialize and new features are delivered in due time, when we were promised teams would self-organize and work towards the goal of delivering value fast? Why, despite all of the commendable displays of teamwork, do projects continue to fail and people involved get tired, demotivated and miserable? Why the fall from grace? The answer is bleak, but I will argue it is not a reason for despair.

It's us. We did this.

As soon as we recognized Scrum as a framework, and the guide as a starting point, we started celebrating "doing our own flavor of Scrum", "finding out what works for us as a team" — before ever just implementing the basics. That is a huge misconception. We can bend and break the rules and fight against them as much as we want, but in the end the fact is Scrum is structured in a certain way because other teams faced certain problems and settled for these practices as the best, or lesser evil. If we deviate from them, we can’t expect to achieve the fast delivery and customer satisfaction Scrum promised, and can’t complain about that either. Let's face it — we did this. Now how do we get out of it?

Take a look at the points below — these are things I have seen and faced in different projects, and which seem to be ubiquitous nowadays in the average software project. But if we think hard about these practices, we may realize they are at the root cause of many of our malaises as teams and companies -- and may just be plain anti-patterns!

Corrupting the Scrum Masters.

Strong words to start with? Not when there are many companies assigning the Scrum Master role from one day to the other to previous project and delivery managers, or team leaders without any sort of Agile coaching or training involved, just because management heard there is this thing called Scrum which all the cool companies are doing. If you're reading this article and you just blushed, you know what I'm talking about!

With all due respect to POs and team members, the pivotal role in Scrum is the Scrum Master. Worse than a weak Scrum Master who doesn't have the capacity to shield their team from external interference is only a Scrum Master who is actually a delivery manager or project manager, whose sole task is to report on progress daily, manage endless spreadsheets and project reports and brings interference to the functioning of the team on a daily basis, as the business pressures threaten to derail work with changes sometimes from one day to the next. One would hope it is obvious, but let's cite just a couple of the dangers of this:

• The sprint goal is constantly put at risk, or ends up disappearing as a concept: when heat comes from above, a Scrum Master should be able to say no to management and protect most of the original agreement for a sprint, or ask the PO to cancel/early terminate it if the priorities changed that much. But if you push the team around daily with random goals, at the end of the sprint you will achieve nothing you had originally planned for, threatening the long-term plans/goals of the company.
• Team morale shrinks. The Scrum Master should be the strongman of a team, the solid wall protecting other members from external noise, letting them perfect their work, inspect their processes and unblocking them whenever necessary. Is it humanly possible to fulfill that role in places where a Scrum Master is expected to be constantly reporting, bogged down in numerous meetings? It is totally acceptable for the PO to check on the progress of the sprint towards the goal, but the Scrum Master shouldn't be abducted to be doing that reporting 24/7, or you will have an abandoned team pushing in different directions trying to help themselves in the daily work.
• Standup becomes a status reporting meeting, where it should really be about team members sharing information with each other, foreseeing their daily work. I decline to comment further, as you have probably seen that already live.
• Proactivity decreases in the team: if someone is always constantly checking on the progress of the work, why should a team member put forward concerns and act proactively towards progressing on the goal of the sprint? He is not being paid more for that. This is capitalism, guys!

So what to do? Accept the Scrum Master is supposed to be a difficult figure, and hire for that. It takes a big amount of maturity to accept that, but if a Scrum Master is best friends with all the project managers and there is no conflict, who is defending the team? Hire strong Scrum Masters: you may not like what they will do, there will be confrontation, but the overall efficiency and output of the team will grow exactly because of that. Accept that this conflict is positive, and stop corrupting your Scrum Masters to become delivery managers. Foster independence and proactivity inside the team instead, with the Scrum Master being a point of support for team members who need more help.

Misusing the term “story” if we trace it back to its intended purpose.

Do you have separate story tickets (sometimes assigned to a delivery manager, sometimes to one of the many developers involved) floating around, sometimes in a sprint, sometimes forgotten in the backlog, sometimes put in progress, and you “link” or “split” task tickets which are where you are referring to during our work and daily updates? Are the tasks the items actually being updated, while you have to manually move the story along to… some state? What is behind this disconnect? Isn’t the team's goal simply to have the ACs of a given story fulfilled and declare it done pretty soon (i.e. somehow checked and fit for release)? Isn’t that why we timebox a sprint to (usually) two weeks? Some of the dangers of this:

• Increased administration: you defined how your story must be tested and considered accepted, now you must define what the first task is about, how to consider to accepted, then the second task… but do you even care? Isn’t finishing the story enough, whether we do it in one or three parts, one of us or five people involved? You may find the burden of writing the tasks is shifted to the devs, who should be writing code and automated tests, not tickets, or you have an overwhelmed PO who writes for longer hours than it takes the devs to prepare a small feature.
• Many lines of conversation are opened; people can talk and add info in the comments of all these tickets at the same time, so no one source of truth. If you put in QA resources later to test this they will never know what to test for; if you need to write documentation for it you have to read through it all to even understand what happened.

So what to do instead?

• Use the Subtask feature in place of Task, so a dev can either work directly under the story if he will fulfill its ACs alone at once, or open various subtasks to represent the work is done in parallel/divided into steps. Check with your Jira administrator if you are enabled to create tasks directly under stories (your configuration may vary). Then keep all of the info about the requirements in the story, only technical info in the subtasks (say, if the developer of the API wants to share what the API became after all with the frontend dev who will connect the UI later in the sprint).
• Use the Task tickets for technical tasks the developers have identified are needed (addressing tech debt, creating new tools, CI, refactoring), and have those compete in the Product Backlog for the attention of the PO (remember accepting 10-20% of technical tasks each sprint save you hundreds of thousands of pounds three years later when a badly-written system would become unmaintainable).

Keeping different placeholder sprints on JIRA to represent backlogs.

Everybody loves a good, organized work surface — and Jira is just inviting you to do some bucketing. "Tickets to refine for the next sprint", "Tech debt", "Tickets to sort out" — all created as placeholder sprints under a JIRA project, with the backlog being just that place where new tickets go when you make a mistake and forget to "organize them". The intention is good, but the road to hell is paved with good intentions...

Suddenly, you got yourself a new step in the process: now tickets must be created, put in a "design" bucket, then discussed and promoted to a "technical analysis" bucket. But there is de facto only one backlog per product, or isn't there? Think about it: there are the items you create to be worked on on a certain project (say, Our Innovative Web Shop), you must refine them to some extent, then you must place them in a sprint (which is an Amazing Squad or a Frontend Team sprint etc). Scrum requires nothing else of you. Must you really confine them to going through n ceremonies? Dangers of this:

• Taylorism: why should we bother with intermediate steps/gates? As a dev I can then start arguing that we must fulfil this extra step and this other extra step before declaring a ticket ready to be pointed, when what Scrum intends is for the exercise to be about using the info we have at the time of refinement (preferably at the cusp of starting the next sprint), making a decision, iterating and possibly failing (but also achieving!) quickly. That is not equal to requiring templates and introducing gates to accept tickets. Another way of visualising the danger: if you imagine the whole process as a Kanban board, from writing the ticket through closing it as Done, each of these “placeholder sprints” are an extra column you are forcing a ticket to go through before it can be delivered (and deliver the expected value to your customer!).
• You end up with hundreds of tickets to sort out: if an item has lost relevance, one of the tasks of the PO is to either move it down the product backlog, or close it to avoid the bias of picking it up six months later when the whole context changed. One sign that something is wrong is if you can never seem to be able to do planning, which means there is no centralized list where a PO can draw a line up to the tenth or thirtieth story in the stack and say: these are the must haves for the next sprint/month/quarter/release… With everything is scattered, you lose the focus on the longer-term goals of the product. Shouldn’t product come first?
• There is a lot of waste in creating items that stakeholders dreamt about, but you may not get resources to work on/not get space to due to conflicting priorities in the unforeseen future.
• Refinement is turned into a chore instead of being organic — not what Scrum suggested.

So what to do instead?

• If your team works on multiple applications, use different Jira projects to organize your thoughts about the product in question, keeping separate backlogs. Then run a "team project" where you don't run placeholder sprints — but rather just pull from the backlog(s) of the product(s) in focus in the sprint in question. Also question whether it is realistic or absolutely necessary that your team focus on more than one product per sprint, as that is not what Scrum was originally conceived for.
• If an item is not deemed ready to be pointed when brought forth for refinement, it simply goes down a bit in the given Product Backlog. It is for the PO to try again and gather the info necessary to make a decision on the ACs, or for the team to introduce tasks to resolve the technical dependencies blocking it, or for the Scrum Master to facilitate informing the upstream team they need to deliver a parent feature first. We move, the ticket stays there. It is painful, and it should be — we should be compelled to do something about it, not hide it away for later in a parallel backlog.

Separating refinement and sprint planning.

Are your POs demanding you arrive to sprint planning with all items pre-pointed and ready (which you strangely always fail to achieve?). Frustrating, isn't it? There is no ceremony in Scrum called Refinement Session, yet countless companies seem to have institutionalized one. Scrum intended for items to be refined at the last possible moment — this is why it mentions an up to 4-hour-long (!) sprint planning where the items are discussed (refined), pointed and accepted. A 4-hour-long meeting is simply inconceivable for managers, and it does sound painful to sit that long now that we are in the context of remote teams, but what you have to realize is the same amount of hours or more will be spent by people on Jira comments and Slack/Teams during the sprint to work out the details of the tickets. Is it really not worth to sit a bit longer together and getting input on the items as a team instead of then having parallel lines of communication about the feature, potentially delaying and endangering delivery? Dangers of this:

• An item is planned during the current sprint to be ready for going into the next one — on the day of sprint planning business priorities change for any reason and all of the effort to refine and point it ahead goes to waste. Two hours of refinement times the number of developers involved that could have been used for development towards the current sprint goal!
• If we are constraining ourselves to only having 1 hour per sprint or per week to refine items, instead of spending the time needed to make the item understood and startable, you run the risk of not having enough backlog by the next sprint planning. Have you felt some of your sprints were underutilized, or are they simply changing theme midway as you run out of work and have to call emergency refinement sessions to fill in the gaps, as the PO is prohibited from terminating the sprints earlier not to deviate from the sprint timeline other teams in the company are doing?

Suggestion:

• Hold a longer sprint planning split into parts, close to or right at the beginning of the new sprint. Then the PO can call in small (30 minute?) ad-hoc “refinement” sessions to gather early info from the devs on the viability of his next planned features at random points during the sprint.

Holding “low-level refinements”.

Again, there is no such ceremony in Scrum. But if Your Flavor of Scrum prescribes it, I have a provocation: do we prefer accepting a clearly-written story, pointing it, realizing there is a technical impediment during development, delivering a part of it in this sprint (formally: cancelling some ACs) and opening a new story for the rest, all in some days; versus spending four weeks discussing the feature, passing the stories through fixed weekly meetings, creating technical blueprints, then in the middle of development still finding something we didn’t anticipate, and we now lost six weeks without delivering anything? A story should contain the point of view of the business — it’s up to the team to decide how to make the story come true technically, at the point where they pick up the work from the sprint backlog. A story should also be an open point for discussion. Some dangers of this:

• If devs are insisting all the technical details are discussed upfront, that is a sign our developers don’t trust each other to make sound technical decisions/want to control the decision.
• If time has to be reserved for devs to discuss technical details, it means our team is not self-organising with the intent to deliver on the committed sprint content, but are only doing their job 9 to 5 with its fixed rituals — taylorism, taylorism, taylorism. Wasn't your HR hiring people who are "proactive"?
• If technical info needs to be added to a ticket to enable it to even be picked up, either the team is not sharing knowledge properly, or the PO was not clear about what needs to be done in that ticket so the dev who picks it up knows where to investigate (exception is a purely technical task raised by a dev).

Suggestion:

• A longer sprint planning meeting can be split into two parts: pointing and arguing on the sprint commitment with the PO, then another part where the PO is not required and devs technically analyse the tasks at hand if there is some technical uncertainty/ask each other questions.

Breaking down the In progress step.

Introducing In Review, To test, Under test steps unnecessarily to your Scrum board, and overstretching the review process. Are you committed to delivering the tickets accepted at the beginning of the sprint by the end, or are you trying to perfect the code and doing long reviews/critiques? Why are tickets in review for weeks and weeks with many changes required over and over, with scope being added to them? Can’t a tech debt ticket be opened if we feel something needs to be refactored, we push that onto the backlog for later and move on with the agreed scope? From the point of view of the sprint cadence, why would the PO care if the ticket is still in active development, or waiting review, or being passed around devs for testing? Why aren’t devs proactively going through the PRs and cleaning up the list, speeding up the review and test process?

Not having predictable, reproducible environments for verification.

Assuming you have not reached the Nirvana of automated e2e testing — let's admit it, hardly many of us have — you still have a verification step to somehow try out your features before declaring them done. Maybe you are, necessarily or not, outsourcing this to some QA team, or have some QA resources inside your team who have expertise in this area. But this step must be tied to a staging/demo/QA/UAT/whatever-we-wanna-call-it environment. You certainly don't want to do testing in production environments, but you can't trust the good-old "it works on my machine" either. If you must have builds being shipped to an appropriate QA resource to be tried out in the nature, they must behave the same way they did on whatever development environment you had, and should continue behaving the same in production. It seems to be an obvious point, and it is perhaps the most crucial to software quality, but one many teams are still missing.

To control this, make adjustments to your CI and branching strategy — I won’t list the many dangers here, we have all seen them when a feature which was believed to be completed fails due to a configuration difference or code management mistakes, but I will note by going through this exercise you will also be fostering good practices of thinking about testing and enabling testing, and also reduce the number of bugs, as the need for maintaining multiple environments implies you must automate and create ways of putting up predictable, reproducible environments.

So, is Scrum even for you?

The points above are just some of the anti patterns I have seen and fought against in many different projects, but the list could go on and on. So after such a long and pessimistic article, why did I mention there is no reason to despair? Part of the answer may sound cynical, but implementing Scrum (or any other methodology) is really a learning curve and a long process. We will make mistakes. This article itself may have contradicted the Scrum guide in dozens of places, and may be full of biases from a number of projects and teams I have lived with through the years. It is okay to err, but what I'm arguing for here is hardening our inspection process.

In Scrum, the most saintly ceremony should be the Retro. If you Retro is not catching fire, you have to take the first steps (perhaps some from this article) to motivate your team to discuss their problems. Fight against apathy. If on the other hand your Retro is already teeming with ideas but they have no relation to the foundations of Scrum, you should question: is Scrum even for you? Would your team benefit from a longer, or shorter sprint? How much can you negotiate with your management to change their attitudes which put hard constraints on the normal functioning of Scrum and of a sprint? What about Kanban? How would you reconcile that, and how are you reconciling your current process? Do you need to bring in Agile coaching? Are your devs committed to the Agile transformation?

These are by no means easy questions, but I will argue that we must stop acting randomly, implementing patchwork solutions, corrupting the expected process and patting ourselves on the back for it, pretending to management something is being done to address the serious problems. It is time to think more. Think hard about the meaning and the effect of these seemingly innocent things we do daily. I will wrap up this long rant with a quote from philosopher Slavoj ?i?ek:

My advice would be [...] precisely to start thinking.??Don't get caught into this pseudo-activist pressure.?"Do something.?Let’s do it, and so on"...??So, no, the time is to think.?[...] if the famous Marxist formula was, “Philosophers have only interpreted the world; the time is to change it” [...] maybe today we should say, “[...] We maybe tried to change the world too quickly.?The time is to interpret it again, to start thinking.”?

It's time to think about Scrum.