Agile Project Management

SYNOPSIS

Has the traditional linear approach to project management left you over budget with an under-developed product and dragged out time-to-market? An agile approach provides greater flexibility, transparency, and accountability for managers with complex projects that require multiple phases of feedback and revision. With this Agile Project Management deck, focus on customer needs with an iterative approach to maximize project success.

PREVIEW

TOOL HIGHLIGHTS

OUTCOME

The agile method of project management can be used by organizations of any size. For large organizations with a legacy issue, agile could especially lead to a more efficient workflow than the traditional waterfall model. With agile, managers can take an iterative and collaborative approach to product development and project organization. Agile's focus is on customer needs and minimizes the resources and overhead needed to create a product with true market-fit. The increased flexibility and rapid pace also create faster turnaround times — the ultimate plus for project managers.

Advantages

Next, we move on to some key advantages of agile, which include better management of priorities, improved project visibility, higher team morale, better alignment between business needs and IT, boosted productivity, and faster time-to-market. The percentages here are editable graphs a project manager can use to assess how these key areas have improved after the switch to agile. (Slide 4)

Process

The agile project management process can be viewed in stages: the prework, the start of the project with the initial set of requirements (let's group them as requirements A here), feedback for this first set of requirements and requirements B, then feedback and requirements C. The project requirements are sometimes also known as tasks to be completed during each stage. 

The prework stage is not exclusive to agile. Every project needs a blueprint to kick off regardless of its management methodology. The prework stage could be where managers define product vision, what the project entails, main tasks required, contractual agreements with external stakeholders, and a proposed release plan. Because the whole point of agile is to allow pivoting, the original release plan is more like a general blueprint of where you can go but can be adjusted.

For example, you want to add a livestream shopping feature to an e-commerce site. The prework would be the development of the product vision and how it will integrate with your existing website and user base, the preliminary contractual agreements with talent that will be involved in the first wave of live stream content that will launch with the product, and your original release plan and features.

Now you start the agile process and set out to accomplish the project's "Group A" requirements. For this Livestream feature, let's say your Group A requirements are to come up with a low-fidelity wireframe of how the user interface will work. In the wireframe development, you'll need to create three possible versions, then develop a low fidelity prototype for a few users to test. 

After you gather feedback from your test group, it's time to implement it into the "Group B" requirements to create your next iteration. One of your first tasks at this point could be to analyze and synthesize study results and make sense of them. Another could be to discuss UX changes with the software team, modify the lofi prototype, and create hifi mockups for another round of feedback. Schedule another user group to come in for feedback, then synthesize and implement their input into "Group C" requirements to rinse, repeat, and release.

Now, for comparison, what would this project look like if it followed the traditional model, and not Agile? Your development team would sketch the user interface, come up with a high fidelity prototype, send it off to the dev team to create the perfect version, and launch it fully formed only to discover it confuses the users. At this point, it is much harder and slower to make changes because so many links in the chain have already come together. For every little change, a whole cascade of other changes could be involved. This is why agile can often be more successful and catch mistakes before they become more irreversible.

Process details

A more detailed agile process breaks down the personnel involved in the lifecycle. The project begins with the stakeholders, which could be both internal and external, an executive or investor, or even a user persona with a development request. Their demands are communicated and then translated into project specs. The project specs are then managed by the project or product owner. This team leader prepares reports that will be used to manage the backlog of requirements to be developed and dispatched. In this example, there are three main versions. After each version's release, there will be a backlog of areas for improvement (based on feedback) to implement before the next release. (Slide 6)

These sprints are then reviewed in a meeting where the team presents the result for feedback that is implemented into the next sprint. A sprint backlog is then used to split the work into smaller packages or allocated to smaller teams and document the remaining work for each package. The idea is to shape the product in increments of improvement so that each sprint accomplishes some level of potentially shippable functionality. Finally, daily scrum meetings, often lead by the scrum master, confirm everything is going the right way. 

To segment by psychographic profile, break down your customers by lifestyle, personality, values and interest. For instance, let's say your target customers follow the lifestyle of an urban professional. Their personality is curious with a love for new innovations and the latest gadgets. They value stability, fluidity and ease of use, and they have an interest in everything from arts and entertainment to tech. However, their unifying interest is to accomplish daily tasks easier.

Let's say you want to use this visualization as part of your daily scrum meeting. You can actually edit this information to list the details you want to review under each element. For instance, under product backlog, you can replace the bullet points with the requirements that still need to be implemented. Under sprint, you can summarize the current status of the sprint. Your Sprint backlog card will cover what still needs to be accomplished. (Slide 8)

Kanban

Another useful agile method is Kanban. Kanban Methodology visualizes a lean workflow in a notecard format, with columns that correspond to steps of the development process and cards assigned for individual tasks. Kanban makes policies explicit with a collective definition of the process and agreed-upon guidelines, and naturally creates a feedback loop for continuous improvement through regular meetings. Also, Kanban makes it easier to manage workflows through the reduction of bottlenecks since everyone can see where the hold-up in the chain is. And because it limits the ongoing work to prevent multitasking, Kanban doesn't overburden team members.

You can use the colors to represent individual team members and the tasks they are assigned. The Kanban board is made up of a backlog of tasks, tasks that have been accepted, and tasks that are to be implemented, tested, and then completed. 

With the livestream shopping feature, the backlog would be all the tasks that we previously defined, like the wireframe development, the UX features, and any coordination with talent or test groups that needs to be managed. As the project manager, you will take tasks from the backlog and assign them to individual team members. As you can see, maybe the main software developer is light green. Here they have three tasks in their to-do and one in progress. The partnerships coordinator, who is in charge of managing talent, is in dark green. In this case, all of their talent acquisition-related tasks are done, as the contracts have all been signed with the influencers who will test and provide feedback then release content at launch. (Slide 11)

Roadmap

An agile roadmap can be used as a project timeline to track progress across multiple years. In this visualization, three different workstreams can be tracked across the years and are color-coded by project risk level. Project Risk Management is important as there can be uncertain events or conditions that disrupt a project's process. Awareness of possible outcomes or possible disruptions better prepares both manager and stakeholder. 

For projects or tasks that are high risk, you can see where to focus your attention, or adjust task priorities so another key task isn't entirely contingent on the success of a high-risk task. Ideally, a task that follows a high-risk task can be carried out despite the success or failure of the high-risk task.

In the case of the live stream shopping feature, a delay to sign up content creators could lead to a weak launch with not enough content to keep your user base engaged, or even know how this new feature works. Another high-risk task could be the creation of the creator dashboard where creators upload their content. If this backend is not set up properly, no one will be able to upload their content or watch livestreams, which would effectively kill your launch. (Slide 13) 

Alternatively, an agile release plan is another type of roadmap project managers can use to track timelines across different versions and releases. It's more of a phase-based visualization that tracks tasks and progress across iterations, which can be helpful variation depending on what information you need to track or communicate with key stakeholders at various stages of the project. (Slide 15)

RELATED