Agile Project Management Techniques and frameworks – L&D – (Section #3 -09042017)

10. The Agile Roadmap

The Agile Roadmap can be described in the following stages:

• In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is?, how it will support your company or organization’s strategy?, and who will use the product?. On longer projects, revisit the product vision at least once a year.

• In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a loose period for when you will develop those requirements. Identifying product requirements, then prioritizing, and roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revise the product roadmap at least twice a year.

• In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes three-to-five iterations. Create a release plan at the beginning of each release.

• In Stage 4, the product owner, the master, and the development team plan iterations, and start creating the product within those iterations. Iterations planning sessions take place at the start of each iteration, where the scrum team determines what requirements will be in the upcoming iteration.

• In Stage 5, during each iterations, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have.

• In Stage 6, the team holds a iterations review. In the iterations review, at the end of every iterations, you demonstrate the working product created during the iterations to the product stakeholders.

• In Stage 7, the team holds a iterations retrospective. The iterations retrospective is a meeting where the team discusses how the iterations went and plans for improvements in the next iterations. Like the iterations review, you have a iterations retrospective at the end of every iterations.

11. Agile Project Management Roles

It takes a cooperative team of employees to complete a project. Agile project teams are made up of many people and include the following five roles:

• Development team: The group of people who do the work of creating a product. Programmers, testers, designers, writers, and anyone else who has a hands-on role in product development is a member of the development team.

• Product owner: The person responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer’s needs and priorities. The product owner works with the development team daily to help clarify requirements. The product owner is sometimes called a customer representative.

• Scrum master: The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator.

• Stakeholders: Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project’s outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies.

• Agile mentor: Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level.

12. Agile Project Management Artifacts

Project progress needs to be measurable. Agile project teams often use six main artifacts, or deliverables, to develop products and track progress, as listed here:

• Product vision statement: An elevator pitch, or a quick summary, to communicate how your product supports the company or organization’s strategies. The vision statement must articulate the goals for the product.

• Product backlog: The full list of what is in the scope for your project, ordered by priority. Once you have your first requirement, you have a product backlog.

• Product roadmap: The product roadmap is a high-level view of the product requirements, with a loose period for when you will develop those requirements.

• Release plan: A high-level timetable for the release of working software.

• Iterations backlog: The goal, user stories, and tasks associated with the current iterations.

• Increment: The working product functionality at the end of each iterations.

13. Agile Project Management Events

Most projects have stages. Agile projects include seven events for product development. These events are meetings and stages and are described in the following list:

• Project planning: The initial planning for your project. Project planning includes creating a product vision statement and a product roadmap, and can take place in as little time as one day.

• Release planning: Planning the next set of product features to release and identifying an imminent product launch date around which the team can mobilize. On agile projects, you plan one release at a time.

• Iterations: A short cycle of development, in which the team creates potentially shippable product functionality. Iterations, typically last between one and four weeks. Iterations can last as little as one day, but should not be longer than four weeks. Iterations should remain the same length throughout the entire projects.

• Iterations planning: A meeting at the beginning of each iterations where the scrum team commits to a iterations goal. They also identify the requirements that support this goal and will be part of the iterations, and the individual tasks it will take to complete each requirement.

• Daily scrum: A 15-minute meeting held each day in a iterations, where development team members state what they completed the day before, what they will complete on the current day, and whether they have any roadblocks.

• Iterations review: A meeting at the end of each iterations, introduced by the product owner, where the development team demonstrates the working product functionality it completed during the iterations.

• Iterations retrospective: A meeting at the end of each iterations where the scrum team discusses what went well, what could change, and how to make any changes.

14. Agile Project Management Process Framework (APM)

The process needs to embody the principles mentioned above. It defines APM framework as a series of steps that takes a project from an initial vision of product to the final delivery of product. There are five different phases of Agile Project Management framework that occurs within a project development. Below are the phases of APM framework:

• Envision

• Speculate

• Explore

• Adapt

• Close

The APM process and its phases are depicted in below:

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?’

Without a vision, all other efforts of creating a successful project will not bear fruit. The truth is, creating a compelling vision is very challenging. It takes work and leadership. Due to the myriad of paths that can be pursued it can often be daunting to create a cohesive vision. Compounding the problem is there is in fact no fixed rule for creating a great visionary statement. Hence, it is important there is an effective leader to articulate a vision. The purpose of the envisioning phase is to clearly identify what needs to be done and how it is to be accomplished. Saying this, the envisioning phase should help answer the following questions:

• What is the customer’s product vision?

• What is the scope of the project and its constraints?

• Who are the right participants to include in the project community?

• How will the team deliver the project (approach)?

During the envision phase, the vision constantly changes as new information is gathered. Moving on from this stage; however, the vision should be reviewed periodically to ensure a clear understanding by all those involved in the project. From a more technical perspective, the envision phase can be broken down into four practices (vision, scope, community and approach). When creating a vision, a product ‘vision box’ or project architecture could be used to streamline a vision. For example, a product vision box forces the project team to condense information into limited space in a box. With regards to scope, a project data sheet forcing the team to condense key scope plans and limitations on a single page. Limiting the team to a single page or box for example, increases focus and collaboration and is likely to lead to better results. Community involves identifying and attracting the right people into the team, whilst the approach stage focuses on the final delivery process of the project.

The envision phase is the initial phase of project management within an APM framework. In general, after approval of a business case, the agile key members are involved in the envision phase where they collaborate to create the compelling vision for a project. Envision phase identifies customer’s vision of the project, decides the key capabilities required in the project, set the business objectives of the project, identifies the quality objectives of the project, and identifies the right participants and stakeholders of the project and plans how the team will deliver the project.

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 conjectures 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.

There are two crucial components of an iterative planning and development approach- short iterative time boxes and features. Short iterations help to accelerate the progress of a project by encouraging the project team to think with limited time to accomplish all aspects of product development. For example, in iterative development, quality assurance activities are completed upon iterating. Thus, quality assurance staff members have to figure out how to be more effective and efficient than the previous iteration. With regards to features, product development features are driven by first creating a product feature and then an extensive list of the features. Also, since more products are starting to include embedded software, hardware and software features are now strong contenders for feature-driven projects. The first concern for feature-based planning should be to make the process visible and understandable to the consumer team. Often, the project team have allocated their time to making product specifications target the technical and engineering teams at the expense of consumer understanding. The project team should therefore note that features act as an interface between both engineers and consumers, and should work according to the understanding of both. Agile project speculating enables the project team to accomplish the following:

• Determine how the project and its features will evolve

• Balance anticipation of features and design with adaptation as the project unfolds

• Focus on the highest-value features early in the project

• Think about the project, business goals, and customer expectations

• Provide necessary budget and schedule information to management

• Establish priorities for trade-off decisions as changes occur

• Coordinate interrelated activities and features across feature teams

• Consider alternatives and adaptive actions

• Provide a baseline for analyzing events that occur during the project

It goes without saying that everyone accepts the premise that the business world constantly changes. However, few are able to mentally reverse the psychological effects of a past ruled by rigid processes. Thus, speculative phase is a solution for this.

In the Speculate phase, the product vision into a backlog of requirements is translated, the overall approach to meet the requirements is realized and a high level release plan for the product is presented. There are two key activities in the Speculate phase:

The team must come up with at least an initial understanding of the requirements for the project. Each feature will be further broken down into one or more “user stories” for the team to discuss and estimate. The requirements also have to be prioritized so that the team knows in what order to start working on them.

The second aspect is to determine a high level milestone based plan that speculates how long it would take to create those features. This planning happens at multiple levels such as release level, wave level and iteration level.

Explore Phase: Now that we have gained an insight into the first two phases of APM, which are largely based on planned projections, we now draw our attention to the exploratory phase, which is founded on 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. The project manager as the team builder contributes in six ways to project success:

• Focus the team on delivering results

• Molding a group of individuals into a team

• Developing their capabilities

• Providing team with required resources

• Coaching the customers

• Orchestrating the team’s rhythm

Thus, the purpose of the project leader is to create highly efficient exploratory teams. Exploration and experimentation are the foundations of new product development that involve the risk of making mistakes, failing, and then learning from this failure. Project managers should respond by making risk-taking a lot less risky. This can be achieved by adhering to the three explore phase practices.

As the name suggest, in this phase agile team members explores various alternatives to implement and fulfill the requirements of a project. In this phase, work deliveries and testing takes place. Here, the product vision needs to be transformed to a release plan and then to the respective iteration plan. The team works in an iterative manner in the explore phase that means, they take a sub-set of the product’s features or stories and accept it into a plan for an iteration. Then it will proceed to work on the development for the stories. It goes hand-in-hand with the adapt phase, wherein the team learns from the experiences of development and the feedback from the customer.

Adapt Phase: In the adapt phase, the agile team reviews the results of execution, the current situation, performance of the team against the plan and adapt as per the requirements. Adaptation can be changing the approach to project, changing the process, changing the environment, changing the project’s objectives and so on as per the requirements of the customers. Taking feedback, acknowledging it and adapting to the situation based on the feedback is the major work of this phase.

The first practice is team related, and is to deliver on objectives facilitated by effective management of team workload. The objective of workload management is to have members themselves manage the day-to-day activities required to deliver features at the end of iterations. As for technical practices and low-cost change, the objective of low-cost change is to reduce the cost of iterative development throughout the development and on-going support phases of a product. Project teams must (WORD MISSING) to this by getting rid of any ‘technical-debt,’ which is basically the difference between the actual cost of change and the optimal cost of change. It often occurs when project managers try to hurry their way through iterations without taking full consideration of the implications.

Project community on the other hand is geared towards project towards project managers. The objective of coaching and team development is to unleash the capability of the team by helping team members continuously improve their domain knowledge, self-discipline and team skills. Other practices include daily team integrating meetings to coordinate team members’ activities on a daily basis. Participatory decision making to provide the project community with specific practices to make various analytical decisions and finally, daily interaction with the customer team including product manager to ensure the product stays on track to meet customer requirements. Thus, all practices work in synergy creating an effective strategy to explore via various iterative processes.

Close Phase: This is the last phase within agile project management framework. It concludes the project in an ordered manner capturing the project’s key lessons.

15. Agile Project Management Organizations, Certifications, and Resources

There is a big agile project management world out there. Here are a few of the useful links to members of the agile practitioner community:

Agile Alliance: The Agile Alliance is the original global agile community, with a mission to help advance agile principles and practices, regardless of methodology.

Scrum Alliance: The Scrum Alliance is a nonprofit professional membership organization that promotes understanding and usage of scrum. The Scrum Alliance offers a number of professional certifications:

• Certified Scrum Master (CSM)

• Certified Scrum Product Owner (CSPO)

• Certified Scrum Developer (CSD)

• Certified Scrum Professional (CSP)

• Certified Scrum Coach (CSC)

• Certified Scrum Trainer (CST)

XProgramming.com: Ron Jeffries, one of the originators of the extreme programming (XP) development approach, provides resources and services in support of XP’s advancement on the XProgramming.com site.

Lean Essays: Lean Essays is a blog from Mary and Tom Poppendieck, thought leaders in the use of lean concepts within the software development space.

PMI Agile Community: The Project Management Institute (PMI) is the largest nonprofit project management membership association in the world. The agile section of PMI’s website provides access to papers, books, and seminars about agile project management. PMI supports an agile community of practice and a certification, the PMI Agile Certified Practitioner (PMI-ACP).

Platinum Edge: Since 2001, my team at Platinum Edge has been helping companies successfully take their project management practices to a higher level. We provide training classes worldwide and also develop transition strategies and coaching for organizations moving to agile project management. Visit the training section of our site to find an upcoming Certified Scrum Master, Certified Scrum Product Owner, PMI-ACP preparation, or agile overview class near you.