2 © 2014 copyright of Training ByteSize unless otherwise stated. “I’ve always been Agile. I...
17
-
Upload
arron-henderson -
Category
Documents
-
view
212 -
download
0
Transcript of 2 © 2014 copyright of Training ByteSize unless otherwise stated. “I’ve always been Agile. I...
2© 2014 copyright of Training ByteSize unless otherwise stated.
“I’ve always been Agile.
I just never knew it!
A real experience from the 1990s.”
John NeveYour presenter, not the picture!
very early
3© 2014 copyright of Training ByteSize unless otherwise stated.
... as one of the directors of a small software house, proposing that something, claimed to be impossible by many technical experts, should be attempted on behalf of one of our clients.
I believed in my team and I believed in my understanding of the technology. I knew that our client was committed but that this
would be a significantly risky investment for them.
They believed in us and the outcome was totally successful for all parties.
The key to success was a motivated team involving everyone necessary and an approach which could be totally flexible.
Were we Agile?
See what you think ...
I Remember ...
4© 2014 copyright of Training ByteSize unless otherwise stated.
Basic Data Interfaces
The Challenge ...
User Application (COBOL)
Online Transaction Software (Back End)
Mainframe Operating System (ICL VME)
Online Transaction Software (Front End)
Communication Software
The Users ...
...The Data
require no change to application support requirements
The Rules (Requirements) ...
completely replace the online transaction software
require absolutely no user retraining
work within existing ICL software constraints
5© 2014 copyright of Training ByteSize unless otherwise stated.
Our Dilemma...
We ‘knew’ we could do it! ...
but
... we didn’t know (exactly) how we
would do it!
6© 2014 copyright of Training ByteSize unless otherwise stated.
Extracts from the Agile Philosophy ...
Welcoming changing requirements, even late in development. Agile
processes harness change for the
customer’s competitive advantage.
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.
The best architectures, requirements, and designs
emerge from self-organising teams.
7© 2014 copyright of Training ByteSize unless otherwise stated.
Agile Principles and The Way We Worked
“Focus on the business need” ...
save significant licence and maintenance costs
incur no new ongoing costs at all
require no retraining of users
maintain all user functionality
maintain performance
... every decision about requirements and priorities had these considerations at its core and involved input from the business alongside solution developers
8© 2014 copyright of Training ByteSize unless otherwise stated.
“Deliver on time” ...
Agile Principles and The Way We Worked
be ready before relicensing of the ‘old’ system
give confidence of ‘on time’ delivery throughout
avoid a ‘big bang’ shock at go live
... incremental handover to technical and user testing,weekly management ‘checkpoints’, high level (whole project) and
detailed (next period) forecasts, actual reports against all forecasts,regular deviation and planned corrective action reports
9© 2014 copyright of Training ByteSize unless otherwise stated.
“Collaborate” ...
Agile Principles and The Way We Worked
... the development team included developers,business and technical representatives
... the entire development team worked inthe same room together every day
... discussion took precedence over documentation
... problems were shared and jointly solved
... each day started with a ‘walkthrough’
... conversation was not ‘frowned upon’
... successes were shared and enjoyed!
10© 2014 copyright of Training ByteSize unless otherwise stated.
“Never compromise quality” ...
Agile Principles and The Way We Worked
... high level acceptance criteria were agreed up front
... detailed acceptance criteria were agreed incrementally
... testing was iterative (component) and incremental (integrated)
... testing always included users and technical staff
... developers were ‘reasonable’ perfectionists
... every decision about requirements and priorities took account of the need to deliver quality on time to ensure that the business need was met (and the
benefits realised)
11© 2014 copyright of Training ByteSize unless otherwise stated.
“Build incrementally from firm foundations” ...
Agile Principles and The Way We Worked
... essentially considered as not compromising quality
... additionally gave growing confidence to users
... ‘baselines’ were taken of agreed functionality
... software was released (to testing) in increments
... change control was in place to protect baselines
... change control did not stifle change
12© 2014 copyright of Training ByteSize unless otherwise stated.
“Develop iteratively” ...
Agile Principles and The Way We Worked
... basically was trial and error
... gradually homing in on a working solution
... required previous assumptions to be questioned
... required changes to improve existing baselines
... minimised ‘useless’ work and features
... allowed a degree of learning ‘on the job’
... was a very satisfying of working
13© 2014 copyright of Training ByteSize unless otherwise stated.
“Communicate continuously and clearly” ..
Agile Principles and The Way We Worked
... we offered hands on, early user testing
... the team had daily walkthroughs
... weekly management progress reviews
... we had very open team discussions
... we ‘peer’ reviewed and tested
... there was low volume, high quality documentation
... an open and frank relationship existed amongst the whole team
14© 2014 copyright of Training ByteSize unless otherwise stated.
“Demonstrate control” ...
Agile Principles and The Way We Worked
... acceptance criteria agreed up front and in more detail throughout
... overall high level plan and detailed plans as progress
was made
... frequent, regular management ‘checkpoints’
... frequent, regular forecasting and actual reports
against forecasts
... ‘time-boxing’ of development work
to coincide with management
reporting
... open communication
involving all stakeholders as
appropriate
... protection of baselines and
‘flexible’ change control
15© 2014 copyright of Training ByteSize unless otherwise stated.
Philosophy
Principles
Pro
cess
(Li
fe C
ycl
e)
People
(R
ole
s/R
esp
onsi
bili
ties)
Pro
duct
s
Pra
ctic
es
(Tech
niq
ues)
The Structure and Life Cycle of Agile
16© 2014 copyright of Training ByteSize unless otherwise stated.
Agile Project Management and‘Traditional’ Project Management
PRINCE2® is a registered trade mark of AXELOS Limited.
PRINCE2®
- the PRINCE2 Manual
APM- the APM Body of Knowledge
• Overcome poor communication
• Prevent late delivery
• Deliver what the business actually needs
• Avoid delivering unused features
• Stop considering change as a ‘bad thing’
• Achieve early benefits
• Avoid over engineered solutions
Bespoke- organisational processes
All really just common sense, but documented - an Agile approach is also common sense, but is more
appropriate when a full specification cannot be produced at the start – consider combining a
‘traditional’ and Agile approach!
an Agile approach will help ...
17© 2014 copyright of Training ByteSize unless otherwise stated.
We weren’t Agile,but we were very agile!
An Agile method is simply common sense, but formalised – to give all organisations the opportunity to learn from others’ experiences and
best practice
“I’ve always been agile. I just never knew it! A real experience from the 1990s.”
very early
Thankyou for your
interest!
