In the early stages of Scrum, many teams tend to keep old practices alive. Because of their negative impact, they soon become “anti-patterns.” Here are four of them and their respective proposed solutions.

An Anti-Pattern is “a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.” When migrating to Scrum and because the wording used is generally the same, new concepts like “Backlog” or “Priority” are typically understood and treated as before, and so old tools and concepts infiltrate your new schema. New ideas with old behaviors do not get along well, but tradition, repetition, and lack of flexibility are very powerful, and soon enough an anti-pattern emerges. The following is a somewhat arbitrary list of my favorite anti-patterns, why are they counter-productive and how to go around them effectively.

0. “Red, Yellow, Green” statuses: vagueness

Behold! The project status. An Excel spreadsheet with an infinite sequence of to-dos. In the middle, the “status.” Red, yellow and green cells are used to represent… who knows what?. Last time I asked, “Red” was overdue, “Yellow” was about to go overdue and “Green” was OK. But that was my last project, previous to that I also heard “Critical,” “Attention needed” and “Nothing to do” respectively. I assume there are many other interpretations.

The “recurring problem” is the need to know where we are standing and which task requires our attention, the common response is the above mentioned Excel table or even some Gantt diagram along with the infamous color sequence.

This is an old waterfall practice that many project managers are still using and some Scrum Masters inherited. The issue is not that this system is old or classic but the fact that in a Scrum environment it is misleading and ultimately worthless.

Let’s forget about the concept of “project” for the sake of brevity. Setting a “status” to a particular task or phase does not represent, by definition, the “project” status (nor the Sprint status or any status at all). Additionally, there is no need to monitor any status inside the sprint’s timebox (but you may want to try burn-down diagrams that are more appropriate).

Last but not least, “status” has to be defined. Most people consider the status as the relation between remaining effort/deadline, but one could apply any other criteria.

One way or the other we do not have clear and unambiguous information about what is going on in our development process at any given time.

For this particular case, Scrum does not offer a special tool. The obvious reason is that when developing software with Scrum, the concept of phases and statuses does not apply. We have Sprints in which points or any other unit can measure the internal progress. The length of the Sprint and the experience of the team define the scale and the need (if any) that we have for such a low-level measurement.

If our team is part of a more significant structure using other techniques or methods, then the problem reaches other dimensions. To make a long story short, an isolated Scrum team inside a Waterfall structure will not work, but that is a topic for another post.

 In the early stages of the Scrum adoptions, if you have to report some status, make sure you get a good definition of what it means, and then do your best to translate what you know into what they need to understand. You will not get it 100% correct but peace will prevail, and nobody will take it against your team for the lack of clear “status.” Consider introducing new concepts like velocity, burn-down and burn-up charts.

1. Priorities with names: ambiguity

Very common in Ticket systems and every time task assignment is needed. The recurring problem is the need to understand what has to be done first to satisfy stakeholders but most important, to streamline the development process. The common response is labeling the tickets – tasks, epics or whatever you are handling – with a priority value.

When your system is labeled with terms like “Highest,” “Very high” or “Normal,” the is no point in prioritizing. Such words are not useful because they are ambiguous. “Very high” and “Normal” are very subjective notions and in many cases, they only represent the opinion or point of view of the ticket owner, who has no arguments to defend the assigned priority. Given the case where there is more than one item with the same label (for example, two Tickets labeled as “Normal”) there is no way to know which one needs to be cleared out first. Some managers solve the problem by adding extra criteria like choosing the first one in the list or choosing by the level of difficulty or effort. Too often, the developer will have to ping the person in charge and ask. Then again, the priority label has no meaning, and the “solution” is not such a thing.

The Scrum answer to this problem is the prioritization system used in the Backlog. A properly formatted Backlog contains a list of stories with a unique priority value, being 0 the first. The higher the number, the lower the priority. It does not matter which numerical system you use or how distant the items are in the list from one another. As long as the priority field is unique, the list is unambiguous and everyone knows what to do next, without a doubt. 

Ticket systems, to-do lists, and other tools should follow the same schema. Besides transparency, it provides a simple and reliable method to streamline the development process without the need for external assistance. A properly prioritized list allows workers to be independent and more productive in accordance with the agile principles.

If you are suffering from such practices, your way around is to inform people and demonstrate why the text labels are not helping. It should not take you long to succeed in changing the prioritization procedures. Prioritizing with numbers is called “ordering”. You might also want to try another popular system called MoSCoW that is most used with Epics or in early stages of the development process.

2. Carbon Copy and extended audiences: confusion

As much as we believe that “the most efficient and effective method of conveying information to and within a development team is the face-to-face conversation,” distance, complexity and many other factors work against us. This is why written communication still plays a major role in our workplace. Choosing what to say and to whom is a vital skill. In organizations where ownership, independence, and transparency are not deeply embraced, notifications are often directed to a variable amount of recipients in the “CC” field. The first and most obvious effect is that unless explicitly stated in the text, many people do not know what to do with it. If ownership is not established the tendency is to leave it to someone else and very often nothing gets done without further consultation. On the other hand, responsible people that do care, will double check if and how they are affected, starting endless threats. More emails, meetings, and conversations will be required. If a single email (memo, notification, etc.) cannot directly and consistently settle the matter for what it was intended, then it is not a useful tool. At this point, we have to reconsider three concepts: relevance, contents, and audience.

Relevance assures you that only useful and applicable information is communicated. A good content structure makes your message consistent, self-explanatory and self-contained. Finally, the correct audience has to be targeted for the previous two concepts to be true and avoid spamming colleagues. “Simplicity–the art of maximizing the amount of work not done–is essential” and should also be applied to communication. Take the time to improve your writing and communication skills. For a comprehensive analysis on this topic, please see “Six tips for written communication in an interdisciplinary team.

Consider the following: Scrum prescribes only three roles from which one (the Scrum Master) owns no artifact. This leaves us with the Product Owner and the developers. Therefore, the answers that we need can never be far away. Extended audiences, Carbon Copy, and long threats are a clear symptom that the roles are unclear or that we have the wrong person in the wrong role. Go back to the Scrum Guide, then inspect and adapt.

3. Company dialects: imprecision

There are many reasons why a company dialect arises, being “identity” the one that I heard the most in the last years. The recurring problem is, of course, the need to understand each other and the common response comes in the shape of a new vocabulary set or even invented terms, being both solutions counterproductive.

Regardless of its origin and the apparent need for such practices, company dialects are faulty communication tools. They add a complexity layer on top of our natural language, set a distance between the company and the market standards, make the onboarding process of new employees harder and slower, and they create a false feeling of mutual understanding among others. I mean a “false” feeling because in fact, dialects are rarely formally defined and everyone uses the words at own will and based on personal interpretations (otherwise we would not call it “dialect”).

In my own experience, company dialects are very often the result of misunderstanding and lack of knowledge in specific areas (typically management and software development.) “Scrum” means “we have whiteboards”, a “release” is pushing stuff to the production server, the “team” are those guys sitting together in the corner, and the list goes on and on.

Take a look at how many companies rushed into the implementation of the “Spotify Model” – which is not a model at all – with “squads”, “tribes”, “chapters” and so on. A whole new set of misleading terms to express exactly the same things: team, feature, release. etc.

The best solution to deal with company dialects is not to use them. Unless your team, product, and processes are entirely unique and arose under extremely original conditions, a dialect is not needed, confusing and usually redundant. Instead, stick to the standards. Your way around this situation in your daily life is: replace, explain, repeat.

Replace misplaced words with IT standards, explain why you do it and take the time to tell why the dialect commonly used word is wrong. Repeat the process in every meeting and written documentation. There is a high risk of being unpopular, but you will be doing the right thing. Eventually, your attitude will start a domino effect among your colleagues, and even if you only achieve “partial” success, you will be setting a precedent. Remember: “The Scrum Team members have the courage to do the right thing and work on tough problems. “

4. Meeting syndrome: miscommunication

The sixth principle of the Agile Manifesto prays: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Apparently simple, it is very often misapplied generating the opposite effect of what it was intended for.

In an agile environment, “face-to-face” must be understood as availability and proximity. The intention is to keep people and ideas moving, to get the information that you need as fast as possible, openly and without the need for unnecessary procedures. If the data is available, you get it. If the person that can help you is next to you, then he or she helps you without additional considerations. We do not add procedures, clearances or even formality if they are not unquestionably needed (this is also the meaning of “simplicity”). But we do this only insofar it is possible, safe and meaningful to do so.

Lack of adequate procedures and documentation, together with the spirit of availability and proximity inspired by the sixth principle, very often lead to the celebration of meetings. When the outcome of each gathering is not correctly documented, reviewed and communicated, information gets lost, and more meetings, calls, and emails are needed to recover the missing data and put the team back in track. Soon they fall prey of the “meeting syndrome,” and there are meetings for everything: all the ones prescribed by Scrum but also requirements meeting, planning review, progress review, feedback, performance appraisals, all-hands, announcements, and many others. If you are not careful enough, your day is over before you know it after a swirl of meetings from which there is very little that you can use.

Organized meetings to discuss specific topics “face-to-face” make a lot of sense because you can clarify in seconds long texts, clear out details and bring people together. The key is what happens after the meeting, namely, the follow-up. Adequate monitoring requires written consistent notes, without them there is a high risk of creating an infinite succession of appointments with an incredibly expensive loss of time and energy. Be wary of the meeting syndrome and its ugly sisters, the interruptions. 

References

The Scrum Guide

Spotify engineering culture

No, I didn’t invent the Spotify model