I think we, at times, are caught up in the various agile frameworks out there to where we lose sight of why they exist in the first place. The 12 principles of the agile manifesto isn’t a sort of checklist to judge your organization’s agility. Rather, it offers guidelines for you to focus on the four core values of the agile manifesto. I’ve seen various posts on LinkedIn focusing on which framework to apply depending on the size of the team, cadence of releases, product being released, etc. Though these posts may be well-intentioned, they miss the core value of the agile manifesto — People over processes and tools. Picking a particular agile framework is not meant to be a totally prescriptive exercise. The team should have the say in what framework they want to follow. That’s part of what makes a self-empowered team — self determination.
A couple of clients back, I was working with our development team on an effort to update a legacy application and process into something new and scalable. At the beginning, we elected to follow a scrum methodology. That worked for many months, until we, as a team, discovered that the scrum framework wasn’t suiting our situation very well. We needed more flexibility in handling the work that was coming to us. So, as a team, we decided to pivot to a kanban-based methodology instead. This gave us the additional flexibility in working with changing priorities that we needed. It also freed up some more white space for the developers to focus on their work and release more work items to their customers when they needed it. In short, we embodied the following agile values: Responding to change over following a plan and Individuals and Interactions over processes and tools.
Responding to change
If you are going to respond to change, you have to have the ability to change yourself.
Many companies out there mandate a particular agile framework. This position is understandable as it gives leadership and management a baseline expectation to evaluate performance. However, this position is false as it elevates the process over the ability to change. If a team wants to try something else, pursuant to producing better quality software, quicker, than they should have that freedom. That is why you presumably have an agilist (scrum master, agile coach, coach, etc.) on the team. That person should be able to help the team identify the different ways that things could run. That person should also be able to gauge the intention of the change. If it is a change for reasons other than being better, releasing quicker, or customer satisfaction, the agilist should raise that concern to the team for resolution.
Individuals and Interactions
The main motive for our switch was to be able to facilitate and react to the individuals that were giving us the work better. Business isn’t just a matter of processes and models working in tangent to deliver results. Within those processes and models are actual people. Having quality interactions and treating people as individuals instead of an input point in a process makes a difference. That is why any of the agile frameworks exists. To ensure that people and interactions are at the heart of the process – not to be cogs in that process. That’s not to say that people need to be coached or trained. Certainly there is learning that needs to go on within an organization. But, if you are constantly tweaking a process or adamantly enforcing policy rules, you are elevating process over people.
You need to assess how well your team is centering on people vs. process. It is a delicate balance, but you should be able to gauge where you fall based on the individuals on your team.
Working Software & Customer Collaboration
People define what is working software. There are many sites out on the internet that “work” but are pretty much unusable. In fact, if you go here, you can see websites that worked, but were horrid in terms of the user experience. However, if you click on the links in that article, you’ll notice that some of those websites are different. They are now something that actually “works”.
Software is for people. The agile frameworks exists to facilitate feedback from people in an effort to create working software. If you aren’t interviewing your users, collecting feedback from them early and often, then you aren’t really using the agile frameworks as intended.
Values Matter
In your pursuits for greater agility, don’t lose site of the values. Companies should assess themselves on how well they meet these four values. The twelve principles will help you align to those values. They are not a checklist for your agility assessment.
