Your SlideShare is downloading. ×
A two page primer on agile and scrum
A two page primer on agile and scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A two page primer on agile and scrum

512

Published on

An anonymised 2 page executive summary of how the agile approach to software development differs from more traditional approaches and how the SCRUM framework can help to manage the work stack in an …

An anonymised 2 page executive summary of how the agile approach to software development differs from more traditional approaches and how the SCRUM framework can help to manage the work stack in an agile context. As executive summaries go this is extremely poor as it's too heavy going but hopefully it can be useful source material for someone that has been similarly tasked.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
512
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. An Assessment Of The Scrum Framework Within The Agile Methodology Introduction This report’s purpose is to support an informed decision about whether the adoption of the Scrum framework, within the Agile Methodology, could be beneficial to our IT projects and to make recommendations on how we could move forward in that direction. The reader will gain an overview of the Agile methodology and how it contrasts with traditional (i.e. non-agile) approaches as well as an understanding of the mechanics, advantages and disadvantages of the Scrum framework which offers a way of managing work within an Agile context. The Agile Methodology Traditional approaches such as ‘Waterfall’ rely on being able to identify and finalise the requirements at the outset and then minimising changes as each phase of the software development life cycle is performed in sequence. Such approaches are typically supported by heavy processes, documentation and contracts whilst often lacking ongoing interaction with business stakeholders. Many believe that building solutions in this rigid way has been a key factor in why the IT profession has a reputation for consistently delivering solutions that are inadequate, late and over budget. In contrast, the Agile methodology is one that accepts the inevitability of requirements emerging and changing over time; indeed it embraces these things and thereby aims to improve the business outcomes historically provided by traditional methods. It is defined on Wikipedia as “a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change”. Another key aspect is the “good enough” principle which, if applied correctly, ensures that key artefacts such as code and documentation are neither inadequate nor over-engineered. Subject to there being no contractual barriers, the adoption of the Agile Methodology is most likely to be appropriate where the required functionality can readily be broken down into worthwhile increments and/or where the user experience is central to success (e.g. a website) and/or where the market space is changing rapidly and/or where the functionality or technology is unknown to a significant degree. Whatever the drivers are, working within the Agile methodology raises questions around how fluid requirements can be continually captured, refined, prioritised and incrementally implemented to a deliverable production standard. A widely adopted solution to these challenges is the Scrum framework. The Scrum Framework In 10 Steps 1) Form a small team (5-9 people) that is cross-functional and self-organising. 2) Assign roles to team members in line with the following table: Product Owner Single person representing the business and essentially the team’s customer with a remit that includes: maximising return on investment, prioritising requirements/fixes, accepting/rejecting releases, setting the product vision, setting business expectations. Scrum Master Single person facilitating the Scrum process by: resolving impediments, enforcing time boxes, capturing metrics, shielding the team from distractions, making improvements. Scrum Development Team Member Cross-functional experts (developers, testers, analysts, etc) that execute the tasks, negotiate commitments one iteration at a time, operate with autonomy in a self organised/managed way and collaborate closely with fellow team members. 3) Capture the current requirements in the form of a ‘Product Backlog’ comprising (to the best achievable extent) concrete, manageably sized and prioritised work items for which the relative effort is estimated. 4) Split your timeline into short fixed-length iterations known an ‘sprints’ (usually 2-4 weeks) and plan to deliver shippable (i.e. tested and accepted) features at the end of each sprint.
  • 2. 5) Hold a ‘Sprint Planning Meeting’ with the whole team to identify a high priority subset of the Product Backlog estimated to be equivalent to one sprint’s worth of effort. This subset becomes the ‘Sprint Backlog’ representing the maximum scope of the sprint and is de-composed into granular ‘Sprint Tasks’. 6) During the sprint track the progress of these tasks in short daily stand-up meetings using sticky notes on a board and/or a software tool such as ‘Trello’. Team members report progress, plans and impediments. 7) During sprint execution it’s worth having some form of ‘Product Backlog Refinement Meeting’ to clarify/add/remove/split/re-estimate Backlog items in preparation for the next Sprint Planning Meeting. 8) Backlog Items that are ‘done’ (i.e. tested) by the end of the sprint are demonstrated to the Product Owner (and others) at a ‘Sprint Review Meeting’ leading to the acceptance or rejection of the release. Unresolved items are returned to the Product Backlog. 9) Hold a ‘Sprint Retrospective Meeting’ to reflect on lessons learned and potential improvements. 10) Return to step 5 and iterate. Key Advantages Of Scrum 1) For saleable products and services, early and ongoing delivery of the highest-value features brings forward the point at which revenues are generated thereby accelerating return-on-investment. 2) The focus on making regular ‘shippable’ releases ensures that testing is continually performed. 3) The use of fixed-length sprints provides regular opportunities to change scope and direction. 4) Team members are empowered to own the delivery of clear near-term goals; this is usually motivational. 5) The ability to respond positively and rapidly to change improves customer satisfaction and value. 6) Continual involvement of the Product Owner greatly reduces the risk of delivering the wrong features. 7) High and continual visibility of impediments improves chances of them being addressed. 8) Calculating ‘velocity’ (a measure of team productivity) gauges a sustainable pace for sprint planning. Key Disadvantages Of Scrum 1) Relentless sprints create a stressful sense of being on a high-speed ‘treadmill’ that’s hard to get off. 2) The difficulty of placing an end-date on the project makes stakeholders (especially senior ones) nervous. 3) It’s hard to judge what’s ‘good enough’, sometimes resulting in inadequate artefacts (e.g. documentation). 4) It places a premium on an advanced level of soft skills (e.g. conflict handling) that not everyone has. 5) It’s widely accepted that scaling is a problem, especially if your team is geographically distributed. There is evidence that the desire for co-location is driving a new wave of onshoring which has cost implications. 6) Getting individuals to operate cross-discipline is easier said than done; developers are often reluctant to test and many testers don’t have coding skills. 7) Burndown charts (that measure work progress) can provoke unhelpful management intervention. 8) It’s a fine line between tweaking the various processes to suit the local circumstances (which is to be encouraged) and ‘cherry picking’ in a way that seriously undermines the effectiveness of the regime (e.g. allowing ‘scope creep’ within the sprint and not holding retrospectives). Conclusions & Recommendations Unlike traditional methods, the Agile methodology accommodates change instead of resisting it and maintains a tight feedback loop with the business to maximise the chances of meeting its needs and expectations. The Scrum framework offers an established and popular approach to managing the work stack in an Agile context. Although these approaches are not always appropriate and have some disadvantages, the benefits can be very compelling. However success involves significant process and cultural changes which will require patience and an acceptance that failure and a temporary drop in productivity are likely to be part of the learning process. For these reasons, a high degree of genuine commitment is required, especially among senior managers. With these points in mind, the central recommendation is for us to identify a suitable pilot project with which to attempt a transition to Agile with Scrum. This is in line with recommended practise as it de-risks the learning process by containing the impact of any problems with what can be a difficult journey. This initiative would need genuine sponsorship from a suitably senior client stakeholder. A secondary recommendation is to appoint an experienced Agile Coach/Scrum Master (which <removed> could obviously supply) to improve the chances of success. Finally, it is recommended that some metrics are agreed, at the outset, with which the success of the pilot could be measured in order to inform a future decision on a wider roll-out.

×