Did you know that it is possible to perform Scrum without being Agile – and being Agile is not about following Scrum?I recently participated in a discussion about the differences between the two concepts: Agile and Scrum.<\/p>\n
Many falsely assume that they are Agile simply due to the fact that they perform Scrum in their daily work. It\u2019s a basic assumption, which may have consequences to the success of the team.<\/p>\n
Definition:<\/p>\n
Scrum: A method that introduces a range of roles, artifacts and meeting types.<\/p>\n
Agile: The agile manifesto is the caterpilar for being agile. One of the major factors in the manifest is to understand that it\u2019s a set of values which entails ranking individuals higher than process, working software over comprehensive documentation, etc.<\/p>\n
Do you see the difference?<\/p>\n
If you introduce the mechanical parts of Scrum, meaning distributing roles, initiating artifacts and summon for meetings, without adopting the core values of the agile manifesto – then you\u2019re no more agile than before!<\/p>\n
Heaps of organisations introduce Scrum and follow it \u201cby the book\u201d. It gives a lot of benefits over traditional methods: splitting work into sequential increments (sprints), focusing on improvements (retrospectives) and focus on getting things done (standups).<\/p>\n
Scrum is, as mentioned above, a method. This method takes offset in the agile manifesto, with the agile values as it\u2019s core. If we decompose the agile manifesto and relate it to the elements in Scrum, we see the following:<\/p>\n
Individuals over process: A scrum team is selforganised and will be working autonomously with a scrum master as janitor. In principle, Scrum does not define how the team transforms a requirement (user story), facilitated by the product owner, into a piece of working software which can be verified and approved by the product owner.<\/p>\n
Working software over comprehensive documentation: One of the core features of Scrum is the fact that each increment (sprint) results in pieces of working software that can be considered \u201cdone\u201d. The product ower verified and approves the delivery. Documentation of the software is important, but it\u2019s more important that the software actually works and lives up the expectations.<\/p>\n
Collaboration with the customer over contract negotiation: The product owner role is introduced to build bridges between traditional, detailed, requirement specifications and the working scrum team. The work of the scrum team is being validated and monitored by the product owner through frequent grooming sessions and sprint reviews.<\/p>\n
Responding to change over planning: A product owner ownes the product and release backlog of the team. These backlogs are continously being maintained with special attention to priority and changes in scope. A flexible (agile) approach to requirements management is reached through continuous contact between product owner, scrum master and scrum team.<\/p>\n
If just any of the roles involved (product owner, scrum team or scrum master) does not understand and follow the agile values – the rate of success will drop immediately.<\/p>\n","protected":false},"excerpt":{"rendered":"
Did you know that it is possible to perform Scrum without being Agile – and being Agile is not about following Scrum?I recently participated in a discussion about the differences between the two concepts: Agile…<\/p>\n","protected":false},"author":1,"featured_media":54,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[3],"tags":[5,6],"yoast_head":"\n