Agile Project Management was defined by Jim High smith in his book Creating Innovative Products. The process of Agile Project Management can be classified in the following way:
Initiating: Occurs only once at the beginning of a project or phase
Planning: Being iterative, it occurs at the beginning of the project as well as the beginning of each iteration
Executing: Executes through iterations and so each iteration will see execution activity peaking somewhere in the middle
Controlling: Controlling is about checking progress against plan and taking steps to bring things back on track It would happen hand-in-hand with execution
Closing: Bring projects to orderly closure – would typically happen only once at the end of a project or phase.
APM Framework depicts a series of steps that take you from an initial vision of the product to the final product. Envision and Close usually occurs only once during a project. The various steps in the agile project management framework and the activities involved in each phase can be classified as below Envision helps Creating a high level vision for the project. Speculate helps Creating a high level road map for the project, based on the available information. Typically a release plan and a tentative feature list will emerge from this phase.
Explore is where the team will start creating and delivering the features, exploring various options and innovating as best as they can
Adapt: The team will constantly adapt and change their plan based on the feedback they receive about the completed features and their experiences from developing them.
Close: After the team has generated sufficient value – or whenever the customer has had enough, The project will close and the features delivered will be finalized
Let’s look at each phase in detail
Vision – Vision is expressed in Product Vision during the Envision Phase of APM. Has two characteristics –Clarity & Elevator Statement/Goal
Everybody must be clear what is being tried to be built, and everyone should have same understanding
Goal is a Brief statement designed to impart the intent of the project within two minutes. It is like syou find yourself in an elevator with CEO, you have 2 minutes to explain what you are working on and why it is important
It Defines the beginning of the project, like Kick-off meeting. For shorter projects – Envision and Explore phases can be combined. It involves Development and Product team members in the process with a series of collaborative meeting which identifies the following:
What is the customer’s vision for the product?
What is the scope of the project and its constraints (including the business case)?
Who are the right participants to be included for project community?
How will the team deliver the product (approach)
Product Vision and Scope:
Possible structures for a visioning exercise are to create an elevator statement or a product vision box. The principle of both exercises is to create a statement that describes the future in terms of desired product. Features, target customers and key differentiation from previous or competitive products. This product vision model helps team members pass the elevator test. The ability to explain the project to someone within two minutes.
It comes from Geoffrey Moore's book crossing the Chasm. It follows the form:
For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
Product Vision Box
Product selling points (Front)
Detailed description (Back)
Operating Requirements (Back)
Product Vision Statement
Product Name/Product Category
For, Who, Benefits, Success
Unlike – primary competitive alternative
Our product – statement of primary differentiation
Explains how a project will deliver on the product vision. Mostly in the format of a Project Data Sheet. Single page summary of key business and quality objectives, product capabilities, project management info. Simple document whose condensed format reminds of the strategic
Project Data Sheet:
A project data sheet is a single-page summary of key business objective, product specification, and project management information. It is a document to help focus the project team, management, and customers. The PDS’s simplicity belies its power to convey quickly these key project elements.
It is one of those simple Tools with a powerful impact. Not only does its condensed format appeal to stakeholders who might not be fully involved in the project, And remind those who are fully involved about the most important aspects of the project, it also plays a part with those who develop it.
Sections of the PDS might include some combination of the following, depending on organization and project type:
Clients/customers — a list of the key clients or customers
Project objective statement should be specific, short (25 or fewer words), and include important scope, schedule, and resource information from the tradeoff matrix
Features — a list of the key features
Client benefits — the key benefits and/or selling points of the product
Performance/quality attri- butes — a list of the key performance and quality attributes of the product
Architecture — key architec- tural components of the prod- uct (platform, component, interface, module)
Issues/risks — factors that could adversely impact this project
Translates product vision into backlog requirements which are user stories
Finds the overall approach to meet the requirements including the architecture and/or design characteristics
Two Primary Activities:
Vision of the Product is translated into specific desired features. Each feature broken down to stories.
High level planning to deliver those features
Release Level (all the planned features)
Wave Level (subset of planned features)
Iteration Level (short, time boxed duration to address subset of features)
In Explore phase:
Team starts delivering the working, tested and accepted features in the form of stories. Product vision which has been translated into Release Plans and Iteration plans, Are executed to give project deliverables, meeting the overall mission
Practices followed are:
Deliver on Vision and Objectives with Workload Management
Technical Practices with Low-cost change
Project Community involving Coaching and team Development, Daily Integration Meetings, Interactions with Customer team. DSDM Failure to meet the purpose / solve the problem it was designed for DSDM allows for user testing all through the development process, Thus allowing developers to get prompt feedback on the usability and suitability of the product.
Cost outweighs benefits, or cost is too high altogether - In DSDM, a Business Study is done at the beginning of the project, greatly decreasing the likelihood of late surprises in the financial realm. Poor communication between involved parties
DSDM stresses communication and collaboration between all interested parties - developers, users, etc. The users finds the program either too hard to use that it does not work as expected. DSDM allows for user testing all through the development process, thus allowing developers to get prompt feedback on the usability and suitability of the product. Hidden flaws surface in the system due to poor design or implementation. In DSDM, prototyping helps to ensure that the system is designed correctly and that everyone knows how it will work.
Unit testing helps to uncover hidden bugs, and incremental development allows for user testing all through the development process. Users resist the installation of the system, either for political reasons, or a lack of commitment to it - In DSDM, since the users are actively involved in the development of the system, they are more likely to embrace it and take it on.
The system is in-flexible and/or un-maintainable, and unable to adapt to change. Since DSDM emphasizes flexibility in design, this is not likely to happen with DSDM.