3. What is Agile? Is it a Methodology? No. Agile is a framework
or frame of mind Agile Manifesto
4. Agile Manifesto The Agile Manifesto was written in February
of 2001, at a summit of seventeen independent-minded practitioners
of several programming methodologies. The participants didn't agree
about much, but they found consensus around four main values.
Individuals and interactions over processes and tools Working
software over comprehensive documentation Customer collaboration
over contract negotiation Responding to change over following a
plan
5. Twelve Agile Principles Our highest priority is to satisfy
the customer through early and continuous delivery of valuable
software. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive
advantage. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the shorter
timescale. Business people and developers must work together daily
throughout the project. Build projects around motivated
individuals. Give them the environment and support they need, and
trust them to get the job done. The most efficient and effective
method of conveying information to and within a development team is
face-to-face conversation.
6. Principles Working software is the primary measure of
progress. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely. Continuous attention to technical
excellence and good design enhances agility. Simplicity--the art of
maximizing the amount of work not done--is essential. The best
architectures, requirements, and designs emerge from
self-organizing teams. At regular intervals, the team reflects on
how to become more effective, then tunes and adjusts its behaviour
accordingly.
7. Agile Methodologies The Agile Manifesto does not prescribe
anything There are however a number of Agile Methodologies
8. Agile Methodologies Scrum XP (eXtreme Programming) Crystal
FDD (Feature Driven Development) DSDM (Dynamic Systems Development)
Adaptive Software Development RUP (Rational Unified Process)
9. Agile is Coming Where do the UK and US governments stand on
Agile? National Audit office in the UK (NAO) Government
Accountability Office (GAO) in the USA Two slightly different
approaches
10. National Audit Office (UK) I have found 8 NAO documents
that references Agile, dating back to 2012 The following are
specific to Agile Governance for Agile delivery, July 2012 A
snapshot of the use of Agile delivery in central government,
September 2012 A Snapshot of the use of Agile delivery in central
government, UPDATE December 2013
11. The Other Titles Information and Communications Technology
in government: Landscape Review, February 2011 A snapshot of the
Governments ICT profession in 2011, October 2011 Digital Britain
One: Shared infrastructure and services for government online,
December 2011 Implementing the Government ICT Strategy: six-month
review of progress, December 2011 Efficiency and reform in
government corporate functions through shared services, March
2012
12. A Snapshot of the use of Agile delivery in central
government This was presented at the Agile Event before Christmas
at the British computer society by Alison Terry. Slides are on
Slide Share The approach is to look at case studies where Agile is
being used, and look for examples of best practices and lessons
learnt
13. Government Accountability Office Government Accountability
Office (GAO) in the USA The GAO have produced a number of Best
Practices guides, dating back to 2009.
14. Cost Guide Best Practices for Developing and Managing
Capital Program Costs, Mar 2009 Agile does not appear in 440
pages
15. Project Schedule Guide Best Practice for Project Schedules,
May 2012 Identifies Ten Best Practices Translated into Japanese The
word Agile does not appear in the 220 pages.
16. Agile Specific Paper Effective Practices and Federal
Challenges in Applying Agile Methods, Jul 27, 2012 32 Practices
were identified
17. Common Practices Ten practices were found to be common
across all of the federal agencies surveyed. 1. Start with Agile
guidance and an Agile adoption strategy. 2. Enhance migration to
Agile concepts using Agile terms, such as user stories (used to
convey requirements), and Agile examples, such as demonstrating how
to write a user story. 3. Continuously improve Agile adoption at
both the project level and organization level. 4. Seek to identify
and address impediments at the organization and project
levels.
18. Common Practices 5. Obtain stakeholder/customer feedback
frequently 6. Empower small, cross-functional teams 7. Include
requirements related to security and progress monitoring in your
queue of unfinished work (the backlog). 8. Gain trust by
demonstrating value at the end of each iteration. 9. Track progress
using tools and metrics. 10. Track progress daily and visibly.
19. Challenges The report identified 14 challenges with
adapting and applying Agile in the federal environment: 1. Teams
had difficulty collaborating closely. 2. Procurement practices may
not support Agile projects. 3. Teams had difficulty transitioning
to self-directed work. 4. Customers did not trust iterative
solutions. 5. Staff had difficulty committing to more timely and
frequent input.
20. Challenges 6. Teams had difficulty managing iterative
requirements. 7. Agencies had trouble committing staff. 8.
Compliance reviews were difficult to execute within an iteration
time frame. 9. Timely adoption of new tools was difficult. 10.
Federal reporting practices do not align with Agile.
21. Challenges 11. Technical environments were difficult to
establish and maintain. 12. Traditional reviews do not align with
Agile. 13. Agile guidance was not clear. 14. Traditional status
tracking does not align with Agile.
22. Download Available All the Guides can be downloaded for
free at: http://www.gao.gov/products/
23. Agile and EVM Presented at EVA 18 Agile and EVM white paper
Invited to GAO Agile Experts meeting
24. GAO Update A community of experts help to review and
comment on the Cost and Schedule Guides. Around this time last
year, they decided to include Agile in the appendix of these guides
There are over 75 contributors world wide Cost Guide Appendix still
under development - this will include AgileEVM Schedule guide
Appendix, currently in draft and out for comment this will not
include AgileEVM. Over 800 comments received to date. Will be a
number of months before completion.
25. Overview of Scheduling Guide It Starts by comparing Agile
with Waterfall Lists the Agile Manifesto References the practices
and approach from the GAO, Software Development: Effective
Practices and Federal Challenges in Applying Agile Methods, July
27, 2012 It then discusses if the ten best practice from the
original guide still apply to Agile
26. Ten Best Practices The 10 Best Practices Still Apply in an
Agile Environment with some considerations 1) Capture all
activities 2) Sequence all Activities 3) Assign Resources to all
Activities 4) Establish the Duration of all Activities
27. Ten Best Practices 5) Verify that the schedule can be
traced horizontally and vertically 6) Verify that the Critical Path
is Valid 7) Ensure Reasonable Total Float 8) Conduct Schedule Risk
Analysis 9) Update the Schedule Using Actual Progress and Logic 10)
Maintaining a Baseline Schedule
28. Five Myths of Agile The Paper then identifies FIVE Myths
about agile Discusses each myth Explains why these exist Attempts
to counter the basis for the myth All the myths relate to Agile
Software Development
29. Five Myths The five myths, related to planning for all
activities minimizing the use of constraints assigning resources,
conducting a schedule risk analysis developing and using a schedule
baseline
30. Myth No.1 A schedule does not need to include planning for
all activities, for the entire duration of the program.
31. Why does myth 1 exist? There is a perception that Agile
teams focus only on the short-term; for example, in scrum, teams
are said to have committed only to the work in the current sprint,
while future sprints are provisional because the customer could
decide that the solution is good enough at the end of the current
sprint.
32. Counter for Myth No.1 While Agile emphasizes that only
near-term work is planned in detail (such as just the next sprint),
projects still define their overall goal in a project vision and
typically plan the releases needed to satisfy the vision. This plan
could change or end early, but still provides a high-level view of
the work to be accomplished for the entire duration of the
project.
33. Myth No.2 Programs using an Agile Development methodology
should use constraints to ensure that their iterations remain at a
fixed duration.
34. Why does myth 2 exist? A common approach is to deliver
working software in fixed-length iterations, typically 2-4 weeks
(Sprints). Constraints may appear to provide a straightforward way
to model the fixed start and end dates of iterations.
35. Counter for Myth No.2 Not all activities are constrained to
the sprints. The rest of the world does not operate in sprints:
Interface with stakeholders to get requirements Procurement of
plant and equipment Using resource outside the project, like
subject matter experts Sprints are optional in some Agile
Methodologies
36. Myth No.3 There is no need or less need to assign resources
to all activities.
37. Why does myth 3 exist? The teams are already known for all
tasks and therefore does not need to be explicitly assigned and
managed
38. Counter for Myth No.3 Similar to Myth 2 many activities
require interfacing with resources outside the project, such as
involving subject matter experts and non- labour resources.
Additionally, Agile emphasizes working at a sustainable pace, and
including resources in the schedule can help ensure this.
39. Myth No.4 There is less need to conduct schedule risk
analyses
40. Why does myth 4 exist? Agile embraces change, therefore
using Agile is viewed as a way of mitigating the inherent risk.
There is a perception that explicit risk management practices are
unnecessary When a risk materializes the result is a change
41. Counter for Myth No.4 All projects face risk and
uncertainty . The probability and potential impact should be
examined sooner rather than later For example, the potential impact
of some issues could change the requirement for the number of
teams. Therefore the team size should be considered earlier rather
than later. Agile is about being Proactive not Reactive
42. Myth No.5 A schedule baseline cannot be reliably developed
or used
43. Why does myth 5 exist? Agile welcomes change. As part of
this teams practice just-in-time planning resulting in frequent
changes, this can appear to be in conflict with the concept of
adhering to a baseline.
44. Myth 5 - counter Welcoming change does mean delivery is
undisciplined or ad hoc. A key principle of Agile is to satisfy the
customer early, through continuously delivering the highest
priorities.
45. Counter for Myth No.5 Teams typically develop and deliver
in time-boxed iterations (Sprints) of 2-4 weeks. These iterations
are guided by the project vision, which establishes a high-level
definition of the cost, schedule, and scope. A baseline provides a
basis for specifying expected outcomes for each iteration. As a
result, customers have the ability to hold the team accountable to
the project vision at the end of each iteration.
46. Thank You Thank you for listening Any Questions
47. This presentation was delivered at an APM event To find out
more about upcoming events please visit our website
www.apm.org.uk/events