The high-level backstory to agile manifesto creation started in February 2001. A group of people had a forum where the general consensus was SDLC needed to be able to respond to change during the project. That agreement gave birth to the creation of the agile manifesto and a set of guiding principals for Agile software development methods.
Personal reflections on how to apply the above to my role as a team member who tests:
- Choose tools, language or process that works for the team over my personal preference. Understanding the basic principals of what is under the hood for anything enables me to be a generalist (ability to move quickly side to side).
- Focus on the software working as expected by the Product Owner. Lighten up over the documentation and be creative about how I document it for traceability, visibility and reusability.
- Listen, listen, listen to our customers and get them onboard. They are an essential part of our team, so make them feel like that. If I can, take them on the technical journey with the team and ensure they understand what/why is being delivered.
- Personal experience – I have worked closely with a PO who via emails expressed real unhappiness over certain things in the release. We brought him into the office and all the team (dev/test) walked through the journey. It was amazing and highly effective. Our PO walked out confident in the delivery and he was part of our process. In other words we got our PO to buy into the process and become part of the team.
- Change is OK and it’s really what life is all about. If I need to drop one thing and move on to another I am resolved to do it smiling. Negativity has no place within a highly functioning team but supporting the change (shuffle dancing) does.
I’ve included a link to Wikipedia which goes into the 12 Principles of Agile Methods as well Wikipedia