Background\n\nA few years ago, I transferred from my northeast base of operations down to the Dorset office of my company to work specifically in the ANSWERS software development team in an experience that lasted two fantastic years. In that time, I was exposed to software engineering with some of the brightest, enthusiastic talent and had the opportunity to work on some fantastically diverse projects. One such project even had me giving a presentation at the prestigious annual seminar back in May 2015 as shown below.\n\nThe ANSWERS Seminar, 19th-21st May 2015\n\nI cherished my time in the ANSWERS team in Dorset, where I made some great friends for life and got to enjoy beach life in Poole/Bournemouth. The summers are awesome down there, and our group nights out were the best! Further to this, another brilliant aspect for me was finally being exposed to the Agile Methodology when starting work as a Software Developer on an in-house, internal staff management tool rolled out across our business. Whilst the tool was very engaging and permitted me to build up my core web development skills, it was Agile itself that really piqued my interest due to it being so transferable to other projects and career prospects.\n\nWorking in such a way has had a deep and profound impact on how I approach my work and projects even to this day. It's something that once you see, you cannot... un-see and unlearn the valuable insights that you get. Unfortunately, I know that many are now put off by the very word mainly due to it being hijacked and shoehorned into all sorts of situations which it isn't relevant, and doesn't belong. This is a bit like the excellent but sometimes misunderstood Blockchain technology (but that's another article for another day). No method/technology/framework/etc. in life can apply to everything, let alone be implemented properly with a painless drop-in solution. If anyone tells you otherwise, they have likely misunderstood, are deeply naive, don't understand the subtleties and/or (most likely) don't have your best interests at heart and are trying to sell you something. That's one bit of advice you can have for free!\n\nGuy who is ready to embrace Agile working into his daily routine!\n\nMoving with "Agility"\n\nFirstly, pure Agile has it's roots in software development, and was coined by a group of developers at The Lodge at Snowbird Ski Resort. These developers met up with a shared passion of producing the best software they possibly could 💪. The attendees created a manifesto to enable adopters to "act" in a way that demonstrated that people are the most important part of an organisation rather than talk about "people as our most important asset". They believed that to succeed in the new world of e-business, we needed to remove the meaningless manifestations of "make-work" and "arcane policies", which is something that definitely appealed to me! I have included a link to the manifesto behind it below, along with a link to the detailed history of how the manifesto came into being. I thoroughly recommend that you have a read 😎.\n\nManifesto for Agile Software Development\n\nHistory: The Agile Manifesto\n\nThere are four key elements within the manifesto, which practitioners of the Agile Methodology should value and adopt when embarking on collaborative work. As these elements are available at the link already provided, I have provided my own PERSONAL take as to why they are important based on my work experience below.\n\nIndividuals and Interactions over Processes and Tools: Many organisations (especially large ones) like to focus and rely on processes and tools at the expense of the person(s) in the loop and the human benefit they bring by being involved. Ultimately (prior to robots and AI taking over the world), the work will be carried out by people who collaborate within teams, so constantly restricting behaviour with strict processes and prescribed tools can actually slow down progress in changing environments and completely KILL any form of innovation that you may want. It's difficult to bring about and deliver change when processes have been implemented that ONLY allow for certain outcomes! By instead building an environment which facilitates and empowers people to coordinate, collaborate and be proactive, you will likely see some incredible results!\n\nWorking Software over Comprehensive Documentation: Software-focused as it was coined by software engineers, but still transferable to any project. Ultimate, when delivering a good and/or service, we want it to work as best as we can, thus much of our efforts should go towards this. Comprehensive documentation sounds fantastic, until you realise that few people want to read 304 documents each with 1000+ pages just to do their jobs. You might have covered all the bases with this "rigorous" documentation, but what's the point if only 1% of it is ever read? Is that really the best use of time and project resources? Instead, where I have seen the best success is when we've spent the time improving ways of working, adapting the processes that we use and finding better ways to collaborate which all ensure that the final output ("Working Software" or project deliverables) is of much better quality.\n\nCustomer Collaboration over Contract Negotiation: Take a step back and answer the following question... "What does my client want from me?". It's easy in many industries to think that client contact centers around months of negotiation, contract tweaks, concessions, additions etc, but ultimately, your client is coming to you to do a job they cannot do themselves. This might be because they don't have the expertise, they may not have the time, or for a whole host of other reasons. However, what is ultimately important is that they've come to you to do the job (I've written about this before in the article below). Getting the best contract won't DIRECTLY produce the best outputs as these normally finalised prior to the start of any work and outputs. From my experience, the way you can best give the client what they want is through a strong relationship, regular communications and including them in the process in short iterative feedback loops. This enables you to get to the root problem(s) quickly and thus deploy your solution(s) faster. It's beneficial and fruitful to talk!\n\nResponding to Change over Following a Plan: Plans are VITAL to any success, and I'm a true believer of the old saying "if you fail to prepare, prepare to fail". That being said, the world can be an unpredictable nightmare at times, and will throw all sorts of unforeseen challenges at you to test your resilience (check the date of this article's publication). This is where blindly following your plan, irrespective of what is going on around you will doom you to failure, especially when the plan accounted for a very different operating environment. Responding to change is also INTEGRAL to success, and it is IMPERATIVE that you build an ecosystem which permits changes to be deployed as quickly as possible. If you cannot respond quickly enough to changing environments, even with the best laid plans you will become extinct. Plan to succeed, and tweak the plan when required for sustained progress.\n\nThe Client Isn't Always Right Which is Why they Ask For Your Help\n\nClose nit team embracing the collaborative aspects of the Agile Manifesto\n\nImplementation\n\nTaking this Agile Methodology forward, 12 principles were identified (if you aren't developing software, substitute "software" with "project delivery").\n\nPrinciples behind the Agile Manifesto\n\nWithin a business context, the idea is to have short iterations. No more taking months and months on end to finish a MASSIVE phase and then (finally) take a step back, have lessons learned and operational experience. Instead, you define a shorter period of time (maybe a month) of pure work, finish up, take stock and then go again for another month (or whatever short period that you have decided). Wash-rinse-repeat forever. On top of this, you are ALWAYS looking at how processes can be improved. Don't just settle on a fixed way of doing things and just use it indefinitely for years, decrying "THE PROCESS IS THE PROCESS" every time someone points out improvements. Agile is about producing the best output you can, and "the best" is an evolving concept that changes all the time. If you make your ideas static, then your "best" will start to lag behind others.\n\nThis enables you to best serve your client as by doing this, you have admitted one of the biggest things that we fail to acknowledge whilst working... that we learn more about the project as we work on the project. The idea of knowing everything at the beginning, thus providing an accurate cost, project plan etc is flawed, as you only really get a sense of what is ACTUALLY required when you are working. This is why the best laid plans get delayed, there is scope creep and unforeseen consequences in longer projects. How on earth were you going to predict (for example), that a change of political party 2 years down the line, any war(s), diseases, market crashes etc. would have such a devastating impact on the project when you costed it? Impossible. If you continually update your way of working with what you learn as the project progresses (something that Agile is built for) then you can react to these (and other) changes as they arise. Because you would have the environment for change, you would also be able to pivot quickly limiting the impact of these external events.\n\nThis DOES NOT MEAN that you don't plan/budget etc. Far from it, you create your plan, and work towards it, but in shorter iterations so that you can constantly review how well you are doing, the capabilities of the team and the processes, and allow this continuous learning to shape your work. One of the more popular Agile implementations is Scrum, which is something people can have a look at. I did training for being a Scrum Master and Product Owner, and I'll likely be writing more about these roles in future articles so watch this space 😁! We used a Scrum approach on the projects I worked on down in Dorchester, and I really enjoyed the short daily stand up meetings, short development iteration cycles and the regular "Retrospectives" where improvements were highlighted and then put into practice. You really see tangible results faster, which helps the morale of the team!\n\nScrum.org\n\nEmbracing close client collaboration through the Agile Methodology\n\nWhat Agile Isn't\n\nUnfortunately, as will all great ideas in life, the concept of Agile has been hijacked and the term itself has become a sad buzzword parody of itself. I've gone into organisations we they proudly exclaim "We Do Agile" and "We Work With Agility" and it's really sad to see what they think Agile is and how they've implemented it. At no point has anyone been properly briefed about Agile, where it comes from, or even that the Manifesto exists! Many just spout words in meetings that sound impressive when you first hear them, but when questioned further have zero substance and are being used merely as the flavour of the day. To me, this is a real shame as when done correctly, so many benefits can be realised, but unfortunately in this case, only bad habits have been created.\n\nAgile working doesn't mean hot-desking (seen this), it doesn't mean not having a plan and talking in buzzwords (seen this), it doesn't mean working without a plan (a criticism I've heard). Just because you are using Post-It Notes, Agile Boards or have Installed Jira Software or Trello or Redmine within your organisation doesn't mean that you are working in an Agile manner. You don't even need these tools to work in this manner (they clearly greatly help), and if you refer back to the manifesto, there is ZERO mention of such implementations. Remember, Agile is about People and Interactions OVER Processes and Tools.\n\nWorking with Agile means respecting the four points detailed in the Manifesto, and trying to meet the twelve principles in order to run projects. You still plan, you just acknowledge that plans can and at times will need to change, and you build a framework around this idea. If you are thinking of implementing it, DO NOT allow the Buzzword Bingo brigade to creep in with their absolute NONSENSE! Question what is being said, ask for clarity and justification and do not allow people to say things like "We Do Agile", "We Need to Work With More Agility" etc, or permit anyone to use Agile as definition/justification of hot desking! Make sure that anyone who will be working with the methodology is properly briefed with the meanings, background and benefits so they can appreciate Agile for what it is. We want people to use and enjoy working with Agile, not roll their eyes every time the word is used haha! I've included a link to Buzzword Bingo cards just in case you want a laugh 😂!\n\nAgile Bingo Cards\n\nBuilding a responding to change innovative environment by implementing Agile within our organisations\n\nTaking Things Further\n\nWhen properly understood and used correctly, the Agile Methodology can be invaluable when ensuring that organisations can both follow a plan and adapt to changing environments when required. Fortunately, the original manifesto is simple and made up of four distinct elements, and twelve principles to work towards, which would be an excellent introduction to anyone who is just starting out. Despite the roots in software, the Manifesto can be used on all sorts of projects as long as you substitute "software" for your unique set of outputs. We also need to be mindful that the term has been hijacked as a nice-sounding buzzword, and push back when people start using the term where it doesn't belong. By being smart, we can ensure many successful implementations within our organisations.\n\nTake care and all the best, Si.