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.

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.