‘Read the agile manifesto and reflect on the implications for your role’
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.
- 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