{"id":8106568,"date":"2026-03-31T13:47:14","date_gmt":"2026-03-31T20:47:14","guid":{"rendered":"https:\/\/agilealliance.org\/?p=8106568"},"modified":"2026-03-31T13:47:20","modified_gmt":"2026-03-31T20:47:20","slug":"breaking-eggs-the-case-for-dropping-practices","status":"publish","type":"post","link":"https:\/\/agilealliance.org\/breaking-eggs-the-case-for-dropping-practices\/","title":{"rendered":"Breaking Eggs: The Case for Dropping Practices"},"content":{"rendered":"\n

In February, Derk-Jan de Grood published the article “Skilling Up Development Teams.”<\/a> In it, he argues for the need to consciously and structurally improve the people who build and maintain software. He explains how adopting the right practices can help bridge the gap between the needs of development teams and broader organizational goals.<\/em><\/p>\n\n\n\n

But there is another option that is sometimes overlooked. Teams can also improve by doing less. In this article, Dion Nicolaas explores the power of deliberately dropping practices.<\/em><\/p>\n\n\n\n

<\/div>\n\n\n\n
\n\n\n\n
<\/div>\n\n\n\n

\u201cYou can\u2019t make an omelet without breaking some eggs.\u201d<\/p>\n\n\n\n

The meaning of the saying is that to change something for the better, or to create something new, you have to make changes, and those changes can hurt. If an Agile team wants to improve, they often have to endure discomfort when changing their ways, especially when their old ways feel safe, effective, and familiar.<\/p>\n\n\n\n

The Pain of Change<\/h2>\n\n\n\n

Most people are reluctant to change. When I was the Agile Coach of a team that was formed by merging two teams, I experienced that. There were heated discussions about the way of working, as both former teams thought their way was the best, and even after agreements were made, some team members persisted in their old way, like using the scripting language they were most familiar with.<\/p>\n\n\n\n

Team members felt comfortable with their way of working. When routines changed, they needed to find new ways to do their work. They were forced to rethink why and how they did things. When the team struggled to adopt a new way of working or even obstructed changes, that was not out of malice. It was out of uncertainty.<\/p>\n\n\n\n

No Pain, No Gain<\/h2>\n\n\n\n

But you cannot improve if you don\u2019t change your ways. If your results aren\u2019t very good, if your stakeholders are unsatisfied, or if your team is unhappy, you have to change something. No matter how well thought-out your way of working is, or how brilliantly it has been functioning in the past, sometimes it doesn\u2019t work well anymore. Maybe your work is different; maybe the goals have shifted; maybe your team went through a transformation. But sometimes something needs to change to match the current situation. And change hurts.<\/p>\n\n\n\n

One way to change is to introduce new practices. If you suffer from bugs in new releases and you don\u2019t do pair programming, introduce pair programming. Maybe you’ll catch those bugs before you go live. If you never seem to finish your sprint and you can\u2019t seem to find out why, add confidence voting at the end of your planning session. Maybe you’ll be able to surface the doubt early and adjust your plan accordingly.<\/p>\n\n\n\n

Filling the Void<\/h2>\n\n\n\n

Maybe even more powerful than introducing a new practice is to drop one. Sometimes, a team can overdo a practice. Design sprints go into so much detail that they lead to Big Design Up Front. Mob programming is used for every line of code. Planning Poker\u2122 is used all the time, even to estimate tasks that take less than an hour to complete. Instead of trying to fine-tune these practices, consider dropping them altogether. Dropping those practices can feel like breaking out of a mold, or indeed, out of an eggshell: the team suddenly gets the freedom to do things differently.<\/p>\n\n\n\n

In one situation I experienced, a Scrum team that consistently failed to finish their sprint and lacked focus was doing very precise user story sizing using Planning Poker\u2122. The sizing gave them a sense of precision, but didn\u2019t help them reach their goal. The sizing narrowed their view on the planning to one story at a time, so creating a sprint backlog was just a mathematical exercise.<\/p>\n\n\n\n

We dropped sizing altogether. This forced the team to look at the sprint backlog as a whole, giving them better insight into dependencies and critical paths. After a few planning sessions, things changed for the better: the plan became more realistic, sprints were finished or nearly finished, and focus returned.<\/p>\n\n\n\n

\n

\u201cAfter a few planning sessions, things changed for the better: the plan became more realistic, sprints were finished or nearly finished, and focus returned.\u201d<\/p>\n<\/blockquote>\n\n\n\n

Initially, the team was uncertain about this. The practice gave them guidance, which was now gone. Also, the practice felt comfortable and solid, so now they were suddenly floating. But this uncertainty led to progress. Without the usual way of doing things, the team was forced to look at the bigger picture. What are we trying to accomplish? What is the best possible outcome? And how can we get there?<\/p>\n\n\n\n

As an Agile Coach, I like to create a little bit of chaos for my teams. Not an amount of chaos where nothing makes sense anymore, but more like emptying a cupboard to put things back in in a neater, more organized way. Dropping practices is one instrument to create chaos. I remove the routine, and then let the team come up with new ways to fill the void.<\/p>\n\n\n\n

The Scientific Method<\/h2>\n\n\n\n

There are no sacred practices. A practice isn\u2019t a goal in itself; it is a tool that can help you reach the real goal. There is no given set of practices that you need to embrace to be a hyper-performing team. So how do you choose the practices to implement or abandon? How can you decide which change will lead to which positive outcome? <\/p>\n\n\n\n

That is not an easy question to answer. A good Scrum Master or Agile Coach can help here, as they have the experience that helps them predict the impact of changing practices. But not all outcomes can be predicted reliably. Workplaces are complicated, teams are different, and all people in an organization have their unique effect on the effectiveness of that organization.<\/p>\n\n\n\n

\n

\u201c…not all outcomes can be predicted reliably. Workplaces are complicated, teams are different, and all people in an organization have their unique effect on the effectiveness of that organization.\u201d<\/p>\n<\/blockquote>\n\n\n\n

The Agile way of working is empirical, iterative, and continuously improving. Instead of trying to work out a theoretical model that predicts outcomes, the iterative approach enables you to change something, observe the effects, and then keep the change if you like it, or drop it if you don\u2019t. That\u2019s why a good resolution from a retrospective is often called an experiment<\/em>. It is conducted to see if it affects the outcome of the team in a positive way, and if not, it is abandoned again.<\/p>\n\n\n\n

You don\u2019t have to predict the future too far ahead. Each new adoption, change, or abandonment of a practice can be a trigger for team improvement. If it moves the team in the right direction, good! If it doesn\u2019t, try something else. As long as you don\u2019t stop changing, there will be improvement.<\/p>\n\n\n\n

Never Stop Breaking Eggs<\/h2>\n\n\n\n

So go ahead and break some eggs. Every sprint where the outcome falls short, check if there is a practice that you can adopt, or one that you can drop. Get used to making omelets. Don\u2019t be afraid of cracking those eggs. Improvement comes from change, never from staying inside your egg.<\/a><\/p>\n\n\n\n

<\/a><\/p>\n\n\n\n

<\/a><\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

An Agile team does not always improve by adding new practices. Sometimes the better move is to drop one that no longer helps.<\/p>\n","protected":false},"author":8142671,"featured_media":8106627,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_tec_requires_first_save":true,"_EventAllDay":false,"_EventTimezone":"","_EventStartDate":"","_EventEndDate":"","_EventStartDateUTC":"","_EventEndDateUTC":"","_EventShowMap":false,"_EventShowMapLink":false,"_EventURL":"","_EventCost":"","_EventCostDescription":"","_EventCurrencySymbol":"","_EventCurrencyCode":"","_EventCurrencyPosition":"","_EventDateTimeSeparator":"","_EventTimeRangeSeparator":"","_EventOrganizerID":[],"_EventVenueID":[],"_OrganizerEmail":"","_OrganizerPhone":"","_OrganizerWebsite":"","_VenueAddress":"","_VenueCity":"","_VenueCountry":"","_VenueProvince":"","_VenueState":"","_VenueZip":"","_VenuePhone":"","_VenueURL":"","_VenueStateProvince":"","_VenueLat":"","_VenueLng":"","_VenueShowMap":false,"_VenueShowMapLink":false,"_tribe_blocks_recurrence_rules":"","_tribe_blocks_recurrence_description":"","_tribe_blocks_recurrence_exclusions":"","ep_exclude_from_search":false,"_jf_limit_responses":"","footnotes":""},"categories":[883,908],"tags":[],"content_source":[],"class_list":["post-8106568","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mindset","category-process"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8106568","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8142671"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=8106568"}],"version-history":[{"count":14,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8106568\/revisions"}],"predecessor-version":[{"id":8106638,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/posts\/8106568\/revisions\/8106638"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media\/8106627"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=8106568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=8106568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=8106568"},{"taxonomy":"content_source","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/content_source?post=8106568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}