There has been a lot of interest about Agile in recent years, mainly due to the success in the IT industry; however there is a lot of interest in applying the Agile methods to other types of environment, not just IT.
This conference uncovered some of the myths around Agile, discussed how Agile can be scaled to large complex projects, looked at case studies, talked about Lean Agile and fed back what governments think about Agile.
The presentations sparked some interesting debates, even between the speakers, but soon some common themes started to emerge from each of the presentation.
Agile is not a methodology – it is a way of thinking. There are Agile methods, ranging from project management methods to software development methods but the agile manifesto, which was mentioned almost be every speaker, does not actual prescribe anything.
Being agile is not an excuse to avoid doing things, like planning and risk management. Being agile has a lot of parallels to Lean – you do what needs to be done, no more and no less.
Agile is not new, Julius Caesar used agile, he just did not call it agile. There are a number of companies and projects who are agile, but did not realise it and jumped on the band wagon when a name was given to their behaviour.
Agile is about giving your customer what they want, regardless of what it says in the contract - they have the right to change their minds. Agile is about people and collaboration, not the processes or tools although these do help to be more agile.
After lunch, we had a presentation from Project Place and learnt about their latest collaboration tools, including KANBAN boards. The idea is not new, Toyota have been using them for decades, but they have been given a new digital face lift.
Finally, thank you to our sponsors Project Place, DSDM and APMG, to the speakers for giving up the valuable time for free, and to Anna and Nigel for their support in pulling the event together.
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 Government’s 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.
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.
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
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.
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
Notes de l'éditeur
Just for fun.
On a piece of paper write down 6 numbers between 1 and 49
If you match all six – well done! There is no prize.
You have all heard of the Agile Manifesto – adrian cover this this morning.
It is people Centric – it is about the people not the processes
If in not document centric – working software is more important than documentation
It is not about “what’s in the contract or specification”, its about giving the customer what they want
Embrace change – don’t just blindly follow then plan. As we all know even the best laid plans change.
I have looked at two government offices.
NAO and GAO
NAO – scrutinises public spending on behalf of parliament – reporting results, holding department to account for the way they use public money
The opposite number in the united states
GAO – known as the investigation arm of Congress – looks to improve the performance of federal government
However I did find that the GAO have produced a specific Agile publication.
Why does this myth exist? As Agile emphasizes stable and self-organizing teams, a perception can develop that the resources—i.e., the team—are already known for all tasks and therefore does not need to be explicitly assigned and managed.
Counter the basis for the myth: As discussed above, many activities require interfacing with resources outside the project, such as involving subject matter experts and non-labor resources. Additionally, Agile emphasizes working at a sustainable pace, and including resources in the schedule can help ensure this.