In Agile, we have a concept called the 4 Core Values that we use as a guiding principle for producing software. Before the creation of Agile Methodology, there were many processes in project management that took incredible amounts of effort and time away from the progression of developing software products. Agile was created to “trim the fat” on costly processes and get straight to the meat and potatoes of the product, for lack of better terms.
Therefore, these 4 Core Values are written as “one over the other” statements to shift the focus on progress over process. It can be easily misconstrued that putting one value over another value means that we are disregarding the latter for the former. While it’s important to shift our thinking to create better products, Agile isn’t about dismissing the latter – rather, putting the former over the latter. Based on our professional experience, here’s how we think each statement works together.
INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLS
This value states that the people we work for and the relationships we have with them are more important than the processes and tools that guide the project along its development. Tools are implemented to make our lives easier, so why would we put individuals and interactions over them?
The answer is this: when we get caught up in the tools and processes, they drive the mindset. Agile is designed for flexibility for both the client’s needs and the inevitability of circumstance. Tools and processes are very useful things, but the wrong tool will always do the wrong job. When we value the individual and the relationship we create with them first, we know what tools and processes will serve them and which will not. Tools are better used to guide the people using them, rather than the mindset.
WORKING SOFTWARE OVER COMPREHENSIVE DOCUMENT
If you spend weeks documenting every detail, step, and change of software production, how much of that documentation will you revisit? Furthermore, if you don’t revisit that documentation, did we spend our time wisely?
Agile isn’t free of documentation, but the roadmap isn’t burdened by it either. What Agile does is called “Just In Time” documentation. This is where you produce just enough documentation to aid the development along, without any “just in case” documentation. If the documentation does not aid in the success of the project, it isn’t a good use of your time and effort. We know that you won’t always be able to avoid documentation, but avoiding excessive documentation allows you to focus on what’s important – results. When customers ask us how much documentation they should produce, our answer is always the same: as much as the project needs, and not a stitch more.
CUSTOMER COLLABORATION OVER CONTRACTS
Contracts once dictated every detail of a project’s development. From the details of partnership to what the product was supposed to do, everything had to be agreed upon in writing. In Agile, we understand that what you needed 8 months ago may be vastly different than what you need now. Rather than treat our customer as a separate entity, often we invite members of their organization to be part of the Agile team during production. One of the many benefits of this practice is that we stay informed of the client’s needs throughout the entire development process, rather than stick strictly to what was written at the start.
It is impossible to get rid of contracts entirely however, as written word is much stronger than spoken agreement. The idea isn’t to rid ourselves of contracts all together, but to not allow strict wording to impede on adaptation and progress. If we don’t allow the contract to drive the process, we have the space to collaborate and meet the demands of our customers today.
RESPONDING TO CHANGE OVER FOLLOWING A PLAN
Change is inevitable. New technologies emerge. New compliances arise. New requirements are needed by the client. Building software isn’t like building anything else in the sense that the roadmap is not a straight line. It’s more like a lot of small interchangeable pieces that require constant monitoring and revision.
On the other hand, any project without some sort of plan is doomed from the start. The distinction to make here is that the plan is less law and more guideline. Agile isn’t void of planning – it just takes a different approach. While the traditional waterfall method plans each step of a project’s development, Agile plans for the work that is going to get us the best results right now. When we choose to respond to change, we build better products and stronger trust with clients.
TO SUMMARIZE
The 4 Core Values as they’re presented may understandably get some reactions to those who have spent their professional careers in traditional project settings. It’s important to note that while these values are meant to challenge the traditional methods, it’s not with the intent to do away with the things that work. We use Agile to use what works best for us and to continuously improve on the rest.
Over the course of the coming months, we’re going to dig into these areas in a little more detail to really drive home what makes Agile so successful. In the meantime, if you’re interested in learning more, we highly recommend the link below as it is the basis of all the information you’ve just read!
https://agilemanifesto.org/
