 |
|
Here are the six steps to Agile. At first this all may seem a grey area but you will turn it round and complete your agile project in the end, certainly.
 |
|
-
First, you define survey and develop a project with a requirements list and begin to develop the important features. The project is planned &
documented in the delivery plan. The delivery plan shows the fixed end date of project when your delivery will be made. The release plan shows the
delivery split into a series of shipments. Each of the features of the solution will be delivered as part of one or more shipments. The requirements
list identifies all the features to be delivered and, as the project progresses, it lists those new requirements identified as well as those
requirements delivered and not yet delivered.
-
Handovers are performed by the development team from the development to assessment environments. Handovers between the assessment and the live
environment are performed by the shipment team. The features are developed on the development environment and assessed by the business team in
solution demonstrations on the assessment environment. You will receive development feedback and release feedback from the assessment demos.
-
Release feedback includes requests for shipments, shipment status & shipment re-planning. Development feedback includes positive feedback on the parts
of the development process that are going right and that work well as well as
features to be signed off.
Development feedback also includes negative feedback on the parts
of the development process that are not going well and that need improvement as well as
on features that cannot be signed off, including features that contain defects. All defects and all changes
to features are documented in the build and fix list. Every item in the build and fix list has a unique number, a description and a priority.
The build and fix list is used to identify the priority work to be performed each day. The list is built up, changed and re-prioritised at the
Daily Forum.
-
The Daily Forum confirms project status to all attendees and collects all build and engagement risks. Build risks are any risks to the project
that can be mitigated by actions inside or outside the project. Build risks are maintained and reprioritised in the RAID Log after the Daily
Forum with your business team. The business team will decide which risks are important, which risks will be repaired before shipment is made
and which risks can be left alongside the shipment. The shipment will continue, with the risk or without it. But the business decides.
-
Engagement risks are risks that challenge your projects Engagement Commitments and are the only risks to challenge a shipment or the successful
continuance of the project. Your project responds to statements about Engagement Commitment on the Readiness Declaration. The responses to
statements define a landscape in which your project operates. If engagement risk is identified, it is compared to the criteria for that Engagement
Commitment outlined in the Readiness Declaration in the setup plan. Where an Engagement Commitment is broken then the project, including the project
sponsor, is informed that the project is in Disengagement. This means that the next shipment and the whole project have just 1 working day before it is stopped
(i.e. project resources are removed and formally Disengaged) if the project Engagement Commitment stays broken.
-
Projects that maintain their Engagement Commitments will always deliver business quality solutions, to time and to budget. They have no other
alternative. Failure to commit to the landscape is a demonstration that one or more of the stakeholders is not committed to deliver the project.
There is no way to fail to deliver the project. This is why you use the Toolkit, to guarantee an approach to deliver your project.
We have reached the end of the sixth paragraph.
Now, we need to explore the various agile methodologies.
|
|
|
|
|
|
|
|
|
|
|
|
|
Glossary: »
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
»
|
|
|
|
|
|
|
|
|
|
| | |
| | |
|
 
 SPADE: Successful Pragmatic Agile Delivery Everytime™ |
| Topic: 23 Page: 14/444 Progress: 3.2% |
 | |
|
|
|
|
|
|
|
|
This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL (http://www.bigagiletoolkit.com/) and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™
All rights reserved. |
|
