Agile has been around for over 20 years, and various Agile frameworks have enabled collaboration, reduced waste, and dramatically shortened the time from vision to reality for myriad software projects. It’s not a panacea, but Agile is almost universally accepted as the platform of choice for efficient software development. With some surprisingly simple tweaks, the principles of Agile Software Development can bring the same focus and efficiency to many day-to-day business problems.
Back in 2001, the 17 authors of the Agile Manifesto laid out the values and principles of Agile in detail. It’s worth a first-hand read, but the essence is that some structure is important, but too much structure often slows things down. The overarching values the authors developed were intended for software development, but there are some vital truths that we can apply to business in general.
The first value is to prioritize individuals and interactions over processes and tools. Nobody (including the manifesto authors) is saying that processes and tools aren’t valuable, but it’s easy to lose sight of what people really need when we rely too much on rigid processes and tools. Interacting with people and taking the time to truly understand their perspective is critical to just about everything in business.
The Manifesto also values working software over comprehensive documentation. OK, as written, that one is pretty specific to software development, but if we can allow some flexibility (as agile encourages), changing “software” to “process” opens a world of possibilities. The principle here is instead of spending weeks (or months) building a comprehensive specification that spells everything out in excruciating detail, we will end up with a better result if we start by building something (a piece of software, a process, a prototype) so that we can try it and see how it works. Agile calls this the Minimum Viable Product (MVP). Once we build the MVP and see how it works, we can iterate on the solution to make it better each time. Don’t worry, at some point, we’ll develop proper documentation; as with process & tools, documentation is important…just not as important.
Next is valuing customer collaboration over contract negotiation. A mentor of mine once told me “If you have to use the contract to manage a customer relationship, you don't really have a relationship”. This applies to internal and external customers and stakeholders. Every problem has shades of gray, so if you spend all your time in the black-and-white of your contract, you aren’t focusing on understanding the problem.
The final value is responding to change over following a plan. Back in the day, I remember projects where we would spend weeks – sometimes even months – meeting with stakeholders and developing detailed (many were 100+ pages) requirements. We used those documents to develop a project plan and more technical design documents. Then we went on to development, quality assurance and user acceptance testing, and finally (6-9 months later), we delivered our solution. It was a thing of beauty; everyone was thrilled, and all of us (including the client) agreed that the solution was exactly what the client asked for.
The problem – with astonishing consistency – was that the thing the client asked for a year ago wasn’t what their business needed now. So as soon as the short-lived celebration was over, we started working on filling the gap between the solution we had developed and the solution the client needed now. This is another software example, but it applies equally to many parts of business. Modern business moves far too quickly to spend months building a plan that will be obsolete before the project is done.
Agile is a massive topic, and although the essence of it has survived the test of time, it’s still evolving. The values that I’ve discussed spawn a set of core principles, and from those principles, assorted flavors of Agile have been developed to serve specific use cases and working styles. Outside of the project management and software development worlds, there’s far more to it than most of us need to know. But these timeless values can be a useful guide; the next time you’re working on a project – whether it’s software, process engineering, fixing a workflow, or just solving a nagging problem – take a page or two from the agile manifesto.
Agile has been around for over 20 years, and various Agile frameworks have enabled collaboration, reduced waste, and dramatically shortened the time from vision to reality for myriad software projects. It’s not a panacea, but Agile is almost universally accepted as the platform of choice for efficient software development. With some surprisingly simple tweaks, the principles of Agile Software Development can bring the same focus and efficiency to many day-to-day business problems.
Back in 2001, the 17 authors of the Agile Manifesto laid out the values and principles of Agile in detail. It’s worth a first-hand read, but the essence is that some structure is important, but too much structure often slows things down. The overarching values the authors developed were intended for software development, but there are some vital truths that we can apply to business in general.
The first value is to prioritize individuals and interactions over processes and tools. Nobody (including the manifesto authors) is saying that processes and tools aren’t valuable, but it’s easy to lose sight of what people really need when we rely too much on rigid processes and tools. Interacting with people and taking the time to truly understand their perspective is critical to just about everything in business.
The Manifesto also values working software over comprehensive documentation. OK, as written, that one is pretty specific to software development, but if we can allow some flexibility (as agile encourages), changing “software” to “process” opens a world of possibilities. The principle here is instead of spending weeks (or months) building a comprehensive specification that spells everything out in excruciating detail, we will end up with a better result if we start by building something (a piece of software, a process, a prototype) so that we can try it and see how it works. Agile calls this the Minimum Viable Product (MVP). Once we build the MVP and see how it works, we can iterate on the solution to make it better each time. Don’t worry, at some point, we’ll develop proper documentation; as with process & tools, documentation is important…just not as important.
Next is valuing customer collaboration over contract negotiation. A mentor of mine once told me “If you have to use the contract to manage a customer relationship, you don't really have a relationship”. This applies to internal and external customers and stakeholders. Every problem has shades of gray, so if you spend all your time in the black-and-white of your contract, you aren’t focusing on understanding the problem.
The final value is responding to change over following a plan. Back in the day, I remember projects where we would spend weeks – sometimes even months – meeting with stakeholders and developing detailed (many were 100+ pages) requirements. We used those documents to develop a project plan and more technical design documents. Then we went on to development, quality assurance and user acceptance testing, and finally (6-9 months later), we delivered our solution. It was a thing of beauty; everyone was thrilled, and all of us (including the client) agreed that the solution was exactly what the client asked for.
The problem – with astonishing consistency – was that the thing the client asked for a year ago wasn’t what their business needed now. So as soon as the short-lived celebration was over, we started working on filling the gap between the solution we had developed and the solution the client needed now. This is another software example, but it applies equally to many parts of business. Modern business moves far too quickly to spend months building a plan that will be obsolete before the project is done.
Agile is a massive topic, and although the essence of it has survived the test of time, it’s still evolving. The values that I’ve discussed spawn a set of core principles, and from those principles, assorted flavors of Agile have been developed to serve specific use cases and working styles. Outside of the project management and software development worlds, there’s far more to it than most of us need to know. But these timeless values can be a useful guide; the next time you’re working on a project – whether it’s software, process engineering, fixing a workflow, or just solving a nagging problem – take a page or two from the agile manifesto.
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.png)
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.jpeg)
