Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Agile Antipatterns

DZone's Guide to

Agile Antipatterns

An antipattern is a pattern that you think will improve things, but it doesn't. In this article, the author shares some personal experiences with Agile antipatterns.

· Agile Zone
Free Resource

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

What is an antipattern? It's a pattern that you think will improve things, but actually, it does the opposite. It makes things worse. Sometimes this is visible and sometimes it isn't. The following is a list of antipatterns that I have observed.

Backlog

In Scrum, the purpose of a backlog is to give an idea of the work that is to be done for the project or product to make it a reality. At a high level, it is the Product Owner's vision in coarse grain. When the team gets the backlog, they break down the requirements to determine what needs to be involved.

The undefined backlog takes many forms. One form is that the Product Owner is too busy to define at a high level what they want. They only define the immediate Sprint or two Sprints worth of work. This means that the team has no idea about the long-term vision, only immediate goals. This does not give the team ownership of the tasks.

The product backlog becomes a list of tasks in which the Product Owner has done the breakdown themselves. Again, this takes ownership away from the team. It also means that there may be no coherence between tasks giving the developer little context to go by.

The product backlog does not result in a working component. The best method of measuring an Agile project is in the working software. Something needs to be running at the end of each interval (Sprint) and be production ready. That way, everyone along the SDLC is working on getting something done earlier. Developers develop a working instance; no matter how primitive, testers can test that primitive instance (with caveats). Documentation is done, and at the end, there is always something of shippable quality.

The product backlog is not prioritized or is prioritized in multiple streams even if they require the same skill set, i.e., the items in the backlog are assigned to individuals, not the team. This again takes ownership of the development from the team, and the individual especially if the way the task is to be executed is dictated rather than worked out.

The final, which I have already mentioned, is that tasks are assigned to individuals before the team has a chance to break the tasks down and understand what is involved.

Planning

In Scrum, there are two planning sessions: Sprint Planning 1 and Sprint Planning 2. Sprint Planning 1 is to go through the backlog with the Product Owner and determine what stories or tasks the team will accept for that sprint. This gives context to the team so they are across what the Product Owner's vision is and can get first thoughts of how long a task will take. It gets everyone in line with the product owners vision.

The second Sprint planning session is where the team deep dives into the stories and does the nitty gritty design. Granular tasks are determined and this is where you get the cards for the Sprint. It also serves the purpose of making sure that everyone on the team is across the details of what is happening. It allows team members to contribute to tasks even if they are not involved directly with the task. This also gives the team a sense of ownership in the execution of the task.

The antipattern lies in when management or the team thinks that they know what they are doing and decide they do not need a planning session or they need minimal planning. This could be to save time, reduce meetings, etc. It is actually pretty rare that this is the case and what ends up happening instead is that team members have no idea what is happening during the Sprint. Time gets wasted explaining the situation and sometimes the situation needs to be explained more than once as one team member may ask the same questions as another.

Daily Stand-Ups

Daily stand-ups are there to show the daily progress of the work. You talk to three questions: What did I do? What am I going to do? What is blocking me?

Where the antipatterns occur is when the meeting becomes a status meeting. News is given and the conversation veers away from the progress of the work. This can lead to another antipattern where stand-ups take too long. I've been in stand-ups that have gone consistently over an hour because of this. The purpose of the stand-up is to make people uncomfortable by standing so the meeting is short (no more than 15 minutes). If it goes more than 15 minutes, then people tune out.

Another antipattern is giving a status update to the Product Owner or manager. This is a meeting for the team. It is to let the team know what you are doing and an opportunity to offer help if required.

Another antipattern is talking about tasks that are not recorded either on the board or in the task management software. All work should be logged.

No Showcase

The showcase is where the working incremental, warts and all, is shown to the stake holders. It can also serve as a mini handover session. If there is no showcase, then there is the "opportunity" to skip the working incremental requirement.

Retrospective

The purpose of the retrospective is to look back at what has been done in the last interval and see what can be improved. It is not wishy-washy improvement, either. It needs to be measurable.

A common antipattern when teams first start out is that they struggle with the retrospective and find little to no value in it. They think about dropping it or extending the period between retros in order to save time and do the work. When you do this, you miss the opportunity to analyze what you have done and figure out ways to improve.

Another antipattern is to change how often you have the retrospective. If you are not doing fixed-length sprints (i.e., maybe doing Kanban), then there is the tendency to hold off the retrospective until the end of a development phase. This may be months later. A lot can happen within those months, and without looking back over a short interval, you miss the opportunity to improve.

Retrospectives, when you first start them, can be a little difficult. It's hard to know how to improve and what to improve without an Agile coach or someone who understands the process. What then happens is that the retrospective gets a little superficial. If you are looking back and not seeing any problems, then that is a problem. One thing that Agile does is try to highlight problems. Through fixing these problems, do you get better? If things are getting a little superficial and you are glossing over the problems, then you are not doing retrospectives right.

Finally, not having any tasks set up to do that are measurable is an antipattern. A good guideline is to make SMART goals.

  • Specific
  • Measurable
  • Agreed Upon
  • Realistic and
  • Time Based

SMART goals are a good standard for adding tasks to the backlog from the results of the retrospective. Again, this is how you improve.

Command and Control

When starting out with Agile or Scrum for the first time, it is not unusual for the Product Owner or Scrum Master to be a manager, be it the team leader or higher. When this happens, the old habits of command and control kick in. The manager assigns tasks to individuals in the development team. Tasks are broken down based on hours of work, not story points. In this case, the manager is taking ownership of the tasks away from the team. By assigning tasks, and worse, breaking them down themselves, the manager has kept ownership, and the development team is just a cog in the engine.

This can lead to failure as the team is no longer empowered. They have no say in the solution and thus mindlessly do the work as required. Yes, it is the Scrum Master's role to protect the team from this sort of thing, but if the Scrum Master has no power and all the power is in the Product Owner, the role becomes moot.

Big Bang Improvement

Another antipattern is big bang improvement. A good example is that you need automated deployment. This has been determined part way through a project. Big bang improvement is spending the next three or more months (in my case 12+ months) developing an automated deployment system without iterative or incremental use by the rest of the development team.

Part of Agile is getting value as soon as possible, even if it's not full value. Having some value early on, even if it's not directly related to the production system, is better than having nothing short-term and everything much later.

You also run the risk that your efforts in getting the big bang solution in place do not live up to scratch and add only a little value in real life.

Another antipattern is delaying improvements until there is slack in the schedule. Slack rarely happens, and more than likely will never happen if you do not include the improvements early. The reason for this is that your technical debt racks up and you spend more time fixing the issues rather than improving.

There is an old joke that goes, "How do you eat an elephant? One bite at a time!" ...but if you never take that first bite, you will never eat the elephant.

Education

If you do not know what is required for Scrum or Agile, and you only go by what you see superficially, you are going to fail. Learn what scrum is. Learn its history. Learn how it has been implemented in other industries. For example, it all started with Toyota. Read up on the Toyota production system. A good book is "The Toyota Way" by Jeffrey Liker.

If you jump in without understanding, you run the risk of doing Cargo Cult Agile.

Quality and Definition of Done

An agile antipattern that tends to be done is missing the definition of done or skipping quality checks during the development process.

Quality checks could take the form of not doing unit tests, code reviews, etc. until after development is complete. This could happen days or weeks later and is usually skipped in the interest of time. Why is this a problem? Well, usually, when problems are found out after development, the developer has to get back into the mindset that they were in while developing the feature. This takes time. Then, they have to do the implementation again and recheck.

If the checks are done while development is still in progress, then you save the time that it took the developer to get back into the rhythm. This time saved is usually significantly shorter than the testing task in the first place. There will be a productivity hit initially as you are not used to doing the checks while working, but you will find in the long run that adding the checks actually saves time.

The other antipattern is not defining a definition of done or acceptance criteria. Again, this is left off due to time constraints. But what happens here is that work comes back to the developer because it is incomplete. Why is it incomplete? Well, in this case, the developer didn't know that they had to cater for that situation. Having a definition of done or acceptance criteria gives the developer a perspective on what is required and gives solid checks that they can measure their code by.

Lack of Long-Term Thinking

What is a lack of long-term thinking? This is where the immediate problem is looked at and the overall solution is glossed over. This could take the form of doing the work immediately. You have to repeat the same task anther four times for other environments. Instead of thinking of ways you can quickly automate the process or even semi-automate the process to save a little time in the long run while sacrificing the short term implementation, you just go ahead and brute force the implementation. This means that when you do the task in the other four environments, it's going to take the same amount of time.

Here's an example. Say that you have to do a deployment from Dev to Test. It takes about a day to do the deployment. It is tedious work, but not that complicated.

If you spent two days automating the task, the deployment could be done in an hour. However, you don't have time. You need to deploy now. You spend the day deploying from Dev to Test. When you have to deploy to pre-prod, it takes you a day.

So, far you have taken two days. If you had automated the task, it would have taken two days and two hours.

Now, you have to deploy to prod. If you do the brute force method, you would have taken another day. That's three days altogether. If automated, it's two days and three hours, saving five hours.

The more you have to repeat the task in the long term (let's say there is a bug fix and you have to redeploy to all environments again), the more savings you make time wise.

I think of this problem a bit like the poverty trap. For example, you cannot afford to go to a supermarket. You have no car or public transport. You have to buy groceries from the local convenience store at significantly higher prices, which prevents you from saving money so that you can afford to go to the supermarket to save money.

You need to transcend the work. Look at ways to improve the process in the long-term, not the short-term. Do this continuously. This is called Kaizen and is a major part of the Agile philosophy.

In the antipattern, you are stuck in the poverty trap based on time rather than money.

Another antipattern is that of outsourcing. You need a project done. You bring in outsiders to do the project. Once the project is complete, they hand it over to the BAU (Business As Usual) team, which then has the problem of having to understand what has been built. In the meantime, the people that have all the knowledge have long since left.

Another antipattern is buying pretty toys (tools) without knowing what your requirements are just because they look pretty and simple. However, no one ends up using them because they don't meet the use case.

Lack of Communication

Have you ever been in the situation where you feel that you have been left off something that everyone else knows about? A conversation may have happened at the "water cooler," or the modern equivalent, the coffee machine, that may have affected you, but you were not present when the conversation happened.

Have you been in the situation where you are told, "you should know that," but this is actually the first time you have heard this?

Or, an email was sent months ago. You brushed it off because it was irrelevant at the time and subsequently forgot about it, but when you ask about the topic, you are told that they sent an email. Why don't you know about it?

This antipattern is a big one. Communication can kill an Agile project, especially when you are berated for not knowing something. Morale of the person goes down and so does their productivity.

You need to re-think your communication goals. It is not efficient to send out an email if only half your team takes in the knowledge, or do a hand over for something that won't be used for 6 months. The efficiency isn't in the dissemination of the knowledge, but in making sure that the recipient retains the knowledge.  this can take the form of a one-on-one session, writing details in a wiki page for future reference (Do not use email - it is a horrible interface for knowledge). Write a tutorial.

If something is discussed at the water cooler, get everyone else together and re-discuss the topic. Even if you don't think it's relevant to someone, it might actually be.

Make sure that everything needed at some future point is documented in enough detail that it can be picked up at a later date, for example, six months down the track. Make sure it's in an easily searchable format such as a Wiki.

Finally, do pair programming or mob programming. This is an excellent method of getting everyone on the same page. You may think that it isn't efficient as you have two or more people doing one task on one computer, but there is nothing better for handover than doing the work together.

Not Making It a Safe Environment

This final lot of antipatterns has to do with not making the environment safe. I don't mean taking care of frayed power leads (although you should take care of those straight away). I mean giving an environment where people can speak their mind without being shut down, where dissent is tolerated or even encouraged if it's relevant to the job.

If you do tell those that have different opinions to shut up, then effectively, they may just do that. Then you lose your most valuable feedback, the check to see if you are doing things correctly or not or if you are going down the wrong route.

These are the antipatterns that I have encountered. If you agree or disagree or have some of your own antipatterns that you have encountered, let me know in the comments.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

Topics:
agile ,agile adoption ,anti-patterns

Published at DZone with permission of Holger Paffrath. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}