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?
Craig Nicol 
4 replies on “You have permission to change”
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.
LikeLiked by 1 person
[…] It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need. […]
LikeLike
[…] one thing, and the only way I’ve found success, is to empower the team and everyone within it to make changes. Without that ownership, nothing […]
LikeLike
[…] teams solve disagreements in the open. People first, then process after, to remind everyone of decisions […]
LikeLike