You have permission to change

Agile is a method of managing change by embracing it. It’s not a process, but there are lots of processes that help people deal with their particular change or their particular pain.

We talk about agile a lot as a method of developing code, and how the code needs to be flexible, reviewed, refactored, tested and changed to meet new requirements.

We talk a lot less about the processes around them. Yes, Continuous Integration and deployment are recommended, as are short sprints, and retrospectives should be about making all those better. But there’s too often a disconnect between the people and the processes they create. The processes may get reviewed, but often go without refactoring, testing or changing, so they slowly decay into legacy processes, and procedural debt, that are no longer fit for purpose.

So people work around them and suddenly there’s manual steps in production because a requirement to deal with secure data properly in production didn’t lead to the right refactoring of the CI/CD process.

So what’s your cycle for refactoring, testing, changing and reviewing your processes? Do they live in your code, and subject to the same cycle? Are they accessible and editable by all? Who needs to review them before they change? How do you know they’re failing the test?

Advertisements

One thought on “You have permission to change

  1. 100% – The driving flow needs to be People->Process->Tools. Determine how people can work effectively, and then codify that as a process (then select a tool to support the process). Of course there is a feedback cycle, the selection of tool facilitates or inhibits certain processes, and existing processes have inertia that impacts people.

    For the teams I coach/train/mentor/lead, a significant part of every sprint retrospective is about “the process”. What worked well (do more of that!), what was not so good (do less of that!), and most importantly, what are we going to try differently (never stagnate!).

    Occasionally this leads to the identification of efforts that will take more time than the retrospective itself, and these efforts become items on the backlog.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s