my opinion, one of the areas which gets the most misunderstanding is about engineering requirements in Agile and the codification of all the knowledge that surrounds that. For many , their knowledge of Requirement Engineering is that we take all these really great ideas, write them down and put them in a box until half a year later we open the box with that same information with the same understanding. The problem with this, is that in reality it doesn’t really work that way. This is because our language is never context-free and there’s always room for interpretation and since we are continually evolving, our thoughts, knowledge and understanding of things can shift.
For example, I have worked with people who have misunderstood what the requirements were, simply because the comma was not in the right place, and funny as this may seem, the consequences of misunderstandings can be really detrimental to an organisation and team. So even though we became better and better at understanding requirements within the team, we never really solved anything. I think this is partly because team’s often steer away from codifying and writing down all the information that needs to be understood. Instead we will wait for someone else to come along. When teams are not accountable, lack self-organisation and self-responsibility, nothing ever really gets solved.
When I see this kind of issue arising, I would huddle the team together and look at ways in which we could increase our levels of interaction and communication, and then act on it immediately. Then we verify and validate whether this is the right course of action so that we can move onto the next one. This is the foundation of iterative and incremental product development. For me, if a team is able to do this right, you will really change the way that you are able to conduct and adhere to Requirement Engineering so that you can maximise product value to your customers and within the organisation.
You can maximise your product value and quality by:
Putting together a sufficient ‘definition of done.’
🚀 Ensuring that your product architecture is up to date.
🚀 Making sure interface definitions are up to date after every Sprint.
🚀 Assuring that you have a working product and the correct documentation.
If you’d like to know more about easing the tension between Agile ways of working and meeting engineering requirements, get in touch with Ralph today!
About Effective Agile
Ralph Jocham is a Change Agent in Scrum // Agile // Coaching // Evidence Based Management and also a Professional Scrum Trainer based in Europe.
As one of the first Professional Scrum Trainers in the world, Ralph has worked directly with cocreator of #scrum, Ken Schwaber, and has played an integral part in the course development of the #PSPO (Professional Scrum Product Owner) as well as the delivery of all #scrum.org certified courses.
If you’re looking to invest in training that transforms and empowers teams to successfully adopt #scrum or #agile, and create high-performance #productdevelopment environments leveraging the agile values and principles, visit https://effectiveagile.com/agile-scrum-trainings/
If you would like to work with Ralph and company as an #agilecoach, #agileconsultant, or powerful change agent to get your team back on track and on the road to high-performance #agile #productdevelopment, visit https://effectiveagile.com/agile-transformation/
For more great ‘how-to’ videos, blogs, and insights, subscribe to this channel and visit https://effectiveagile.com/blog/ for more valuable content.
#scrum, #agile, #scrumorg #scrumcertification, #scrumcourses, #scrumtraining, #agilescrumtraining, #agilekata, #agility, #businessagility, #agileprojectmanagement, #projectmanagement, #productdevelopment, #agileproductdevelopment, #switzerland, #germany, #europe, #scrumteam, #scrumframework, #professionalscrumtrainer, #PST, #certifiedscrumtrainer, #certifiedscrumtraining,
