How to manage an Agile project
The myth
“Agile is no place to have proper documentation on active projects.”
The Agile manifesto advises us to focus on working software rather than comprehensive documentation. As PMs, we need to focus heavily on ensuring that the right software is built for our clients. That is why I agree with the priority of Agile – a project workbook that can provide a 360-degree view of our project.
Truth:
The project workbook is a single source of truth. By striking a balance between alignment with the development team and communicating the project progress with the client, it manages all aspects of the project.
There is no specific layout and format to construct a project workbook. However, it is ideal to have a cloud-based wiki that integrates with other tools and applications. This real-time synchronization of all the various information that constructs the workbook is crucial. Over the years, I found Confluence (Atlassian), Google Suite, and Sharepoint (Microsoft) to be very effective foundational tools when creating various project workbooks. The primary goal is to provide a more collaborative, easy to access, and centralized location to get a 360-degree view of a project.
Let’s start by looking at all the elements of typical project workbooks for any given agile project. There are four unique phases: Team ramp up, Discovery, Build, and Deploy. At each phase, documentation is used to optimize the overall project experience.
Team Ramp
From what we know of the Tuckman Model of team performance, the ramp-up phase moves the team very quickly from formation into performance. The objective is to fully onboard the team, taking the time to highlight the main goal and the approach the team has decided on.
Project Background– The equivalent of a Project Charter, it highlights the main objects of the application. Using a deck/ wiki page, it is may be accessed by the project team and enables them to read up on the project information.
Team Register — Describes the team’s roles and responsibilities (Dev, QA, BA…) and generates a spreadsheet with all the names, duties, contact information, and so on.
Stakeholder Register — Extends the team beyond the scrum team to include the product owner and subject matter experts (SME). It will comprise all the names, roles and contact information.
Workflow — From the get-go, the team should develop a comprehensive end-to-end process on how the development is performed during a sprint and define Done. Use the UML design flow within Lucid to outline the development workflow that should link within the team onboard deck.
Tools and Resources — This allows for all the access and credentials to be set up for tools such as Git, Kanban board, etc. A tool checklist allows all the team members to have access to all the relevant tools.
Discovery
This phase looks into gathering enough product requirements to ensure the team builds the right product based on the client’s expectations. While requirements change daily, it’s essential to have the most updated scope bank that the team can access. They are meant to align the project’s resources with the client’s objectives and can take form in many user stories, UX design, context diagram, workflow, etc. Showing how each dimension of the requirement comes together allows the development team to build the right product.
Product Requirement — Typically written in the form of user stories to allow the user and development team to have a common language captured within a backlog for the sprints.
Design Assets — One of the best requirement tools, it gives the user a look and feel of the end product without having a single line of code. Tools such as Sketch, Adobe XD, may be used to create a design space that integrates into the project workbook.
UML Designs and Flow — UML flows and diagrams help to simplify complex systems.
Scope Bank — A centralized area that ties all other discovery assets together, helps the team track out-dated requirements by assigning status (new, open, completed, removed).
Built:
During product development, there are a lot of moving pieces and interactions. Inevitably, product development will generate a lot of information and perpetuate documentation. The PM needs to have the latest information to improve communication and team engagement. The project workbook helps to keep track of all the documents created.
Scrum Sheet — Scrum sessions are less of a status update and more about team alignment and identifying roadblocks. The scrum sheet tracks those roadblocks and next steps, which can be used as a commentary with the burndown chart to understand the peaks and flat lines.
KanBan board — This is the single most important tool to link within your project workbook. The team must be ensured to update their tickets constantly with comments, progress, etc. This helps to track the overall team performance towards meeting the sprint goal.
Meeting Notes — It is crucial to take detailed notes on highlights of the discussion, decisions taken, risk/issues, and next steps. It is very important to capture the owner and deadline. The meeting notes should be circulated within 24 hours or you risk losing the person’s attention.
Risk Register — Risks should be tracked separately from all other updates even though it’s captured within all other artifacts (meeting notes, Kanban board, scrum sheet). The register ensures that the team is aware of all the risks and the potential impact at a glance. Risks should be the main focus of any PM. They are the make or break of any project.
Calendar —Meeting that is the single most important thing any PM does. Keep track of it all by linking your calendar directly to your workbook. There are a set number of sessions that occur within the project. However, the ad hoc ones are the ones that need the PM to be fully engaged on their calendar.
Powerpoint Deck — Leveraging a presentation deck is important for the PM to ensure those within a specific meeting are engaged and are able to follow the information being presented. There are tonnes of different decks to present on but a few that are always constant within a project are Status Update, Sprint Commit, Sprint Review, and Project Kickoff decks.
Share drive (Document hub) — Within a project, reports, documents, design, etc are created which leads to the need for a centralized documentation hub to store and share the information with the rest of the team. Google Drive, Onedrive are some examples of those types of documentation hubs.
Deploy:
At this stage, the focus is to deliver an iterative version of the product within the client’s environment. As such it’s important to document the latest version of the application and any additional information. The single documentation for this job is known as a release note.
Release Notes — refers to the technical documentation produced and distributed alongside the launch of a new software product or a product update (e.g., recent changes, feature enhancements, or bug fixes). It very briefly describes a new product or succinctly details specific changes included in a product update.
Micromoments is a technology company to the core, born out of a strong desire to change the narrative about software development in Jamaica
