Skip to main content

Five Phases of Agile Project

There are FIVE phases that an Agile project goes thru. The FIVE phases are
·         Envision
·         Speculate
·         Explore
·         Adapt
·         Close

Envision Phase: – This phase is to determine the product vision and project scope, the project community, and how the team will work together. The term ‘envision’ is a clear departure from traditional phase names such as initiate and plan, which while subtle, is also significant. This is because when envisioning you inadvertently accept a level of mishap and are therefore ready to make any necessary adjustments, in contrast to a set plan which has more rigorous connotations. The envision phase covers the ‘Who? What? And how?’

Speculation Phase: Unlike planning, speculating establishes a target and direction, but at the same time, it indicates that we expect much to change over the lifetime of a project. Unlike speculation, plans are usually conjectured about the future where people often expect the result to come directly from the plan. Deviations from the plan are therefore viewed as negative unlike with speculation where results are generally viewed as positive. Speculation is only one piece of information that will be examined to determine our course of action when iterating. The result after speculating is a blueprint that outlines information about the products specification, platform architecture, resources, risk analysis, defect levels, business constraints and target schedules.

Explore Phase: Foundation of Explore Phase is “Action”. What is known as a Complex Adaptive System (CAS) is a collection of agents who explore to achieve a goal by interacting with each other according to a set of rules. A CAS experiments with various paths, selects and executes viable ones, compares the results against its goals and adapts as necessary. In a more project-specific sense, the project-manager’s goal is to help the team articulate and understand the goal and constraints, to help the team interact efficiently, to facilitate an effective decision-making process, and to be prepared for the inevitable eventuality of the project going off track.

Adapt Phase: Considering that Agile is of an exploratory nature, requiring speculation and hypothesis testing, it is only logical that a system is implemented allowing for team to respond effectively post-feedback. How a project adapts will depend on a good understanding of the information presented, an assessment of the projects progress, technical risks, and an ongoing competitive market analysis. Reacting to events is, generally speaking, more difficult than reacting to a plan, because the team has to answer three critical questions
·         Are customers getting value from the project?
·         Is the project progressing at a satisfactory level?
·         Is the project team adapting effectively to changes imposed by management, customers and technology?

Close: A project close is both a phase and a practice that is often hurried through at the end of a project. Since available resources are usually scarce, people are moved onto the next project quickly, often without taking time to close up the last project or receiving credit for its completion. This is not only bad for team morale, but it is also a dysfunctional way of organizing a project, as members are unaware of the progress that has been made. There are several activities that should be included in the closing of a project, such as a celebration first and foremost, which serves two primary purposes. It provides a sense of closure to the project and an appreciation for those that have worked hard on the project. Projects that seem to go on and on without any closures are terrible for team morale. Another important activity is to close up open items by finalizing documentation and preparing required end-of-project administrative and financial reports. A final activity is conducting a project retrospective, which has already been done on a more minor scale in the iterative process. The retrospective at the end is primarily for inter-team learning, for one project to pass along to others in the organization the positives and negatives to build upon.

For More Information, Follow the Links below-

Comments

Popular posts from this blog

PRINCE2's Project Organisation

PRINCE2's organisation theme defines the Project Team or organisation. It establishes the project's structure of accountability and responsibilities. As PRINCE2 is based on a customer/supplier environment, it assumes that there will be a customer who will specify the desired result and probably pay for the project, and a supplier who will provide the resources and skills to deliver that result. A successful project management team should have business, user and supplier stakeholder representation. Business The products of the project should meet a business need which will justify the investment in the project. Should also provide value for money. The Executive looks after business interests User The user viewpoint should represent those individuals or groups for whom some or all of the following will apply: They will use the outputs of the project to realize the benefits after the project is complete They will operate, maintain or support the project’s outputs The outputs of t

Scrum Timebox

Scrum relies heavily on the concept of Timebox. Timebox is setting a fixed time limit to any activity and letting other characteristics such as Scope vary. A time box could be ·           A Meeting ·           A Sprint ·           A Test activity ·           Development Activity ·           Or Practically anything such as you chatting with your friend on social networking site. The fact about timebox is that the time is limited. You can adjust other parameters such as ·           How much you can get done ·           Which item you must prioritize ·           However, deadlines cannot be moved. In Scrum, all the project iterations, meetings must be timeboxed and time limits be respected. This is very important and non-negotiable aspect of Scrum. Lets look at how a timebox actually works. ·           Timebox can be of any duration  - hours, months, years ·           It is essentially a control mechanism to ensure how much time you wish to devote

The Service Value System - Continual improvement | ITIL V4 Certification

Continual Improvement Continual improvement takes place in all areas of the organization and at all levels, from strategic to operational. When provisioning a service we should always keep continual improvement in mind, and should always be looking for opportunities to improve. To support continual improvement at all levels, the ITIL® SVS includes: ITIL® Continual Improvement Model provides organizations with a structured approach to implementing improvements Improve Service Value Chain Activity Continual Improvement Practice Continual Improvement Model Continual Improvement Model can be used as a high-level guide to support improvement initiatives.  The model supports an iterative approach to improvement, dividing work into manageable pieces with separate goals that can be achieved incrementally. The scope and details of each step of the model will vary significantly based on the subject and the type of improvement The steps of this model do not need to be carried out in a linear fash