DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป

DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป is a community of 967,911 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Karine Sabatier
Karine Sabatier

Posted on

Change vs disturbance

One of the strong promises of going agile for a team (induced by the term itself) is to gracefully adapt to change. Agile methodologies place a bet: that by adapting to change the team will release a product that will eventually bring more value to its customers.

There are different kinds of change though, for which going agile is relevant:

  • Change of product positioning (a strategic change)
  • Change of priorities (a tactical change)
  • Change in the market stakes (induced by competitors for instance)
  • Change in the Business Model (repositioning value in your model)
  • Change induced by uncertainty (disruptive innovation context)
  • Change in the technical approach (a need to update the tech choices)

"Good change" builds confidence in the future for the team and helps navigating from uncertainty to less uncertainty.

Lacking product vision, changing your mind 3 times about a feature, having no consistency on your priorities (or no idea what they are), continuously introducing emergencies, altering the proper functioning or the stability of the team... these are NOT change. This is disturbance.

Disturbance doesn't help navigating through uncertainty but it adds more noise to it.

To deal with disturbance, agile brings no answer. I'm afraid you'll have to look into self-discipline.

Oldest comments (0)

Find what you were looking for? Sign up so you can:

๐ŸŒš Enable dark mode
๐Ÿ”  Change your default font
๐Ÿ“š Adjust your experience level to see more relevant content