Twelve Steps To Go Agile

A lot of discussion is happening about project economy. A project economy is where skilled people come together to transform ideas into products and services that offer value.

According to an article published in Harvard Business Review, the Project Management Institute (PMI) estimated that the value of project-oriented economic activity worldwide would grow from $12 trillion in 2017 to $20 trillion in 2027, in the process putting some 88 million people to work in project management–oriented roles. Therefore, the project economy requires many skilled and resourceful project management professionals to run it.

Against this backdrop, I felt enthused by this profession and carried out some research on Agile approach to project management, which is increasingly becoming popular. My experience of leading small and medium sized projects also came in handy in writing this article.

• What is a Project?
• A temporary, unique endeavour
• Has a beginning and an end
• Meant for meeting specific objectives or delivering value
• Needs to be completed complying with the budget, schedule, and quality
• Needs a group of people with a common objective and a missionary zeal
• A flexible activity prone to risk and uncertainty

Approaches to Project Management:

There are two prominent approaches to project management, namely Waterfall and Agile. As projects are becoming increasingly fast-paced and prone to risk and uncertainty, the Agile approach is being widely adapted. It is especially suitable for projects that are laden with significant complexity and urgency.

Why Agile?

There are many reasons behind organizations preferring Agile over Waterfall and some of them are given below. The Agile approach…

• Enables the project team to deliver the product in short incremental cycles
• Facilitates communication between the project team and the client at regular intervals, which lets the project team know whether they are on the right track
• Project team gets feedback from the client after every increment/iteration
• Delivers most value in the shortest possible time
• Let’s you find the fastest and best solutions for design and development
• Allows you to pause and re-evaluate your plans as per the rapidly changing conditions
• Enables you to be open to new ideas that let you meet your customer’s needs in a better way

Steps in Executing a Project:

Agile empowers you to govern a project in a scientific and systematic way to deliver optimum results. Here are the steps involved in implementing a project under Agile.

Step 1: Know Your Project

Before embarking on the execution of a project, the project team must pose some questions to itself and find the right answers.

• Who is our customer/sponsor?
• What are the goals/objectives of the project?
• What exactly does the customer/sponsor want?
• Are we completely aligned with the customer/sponsor regarding the objectives/goals that are to be achieved and the value that needs to be delivered?

To be fully aligned with the customer/project sponsor, the project lead/manager must collect the below-mentioned information and even document it.

• Who are your customers/clients/stakeholders for the project?
• Scope of the project (what are included or not included as part of the deliverables)
• A release plan (a detailed schedule)
• Mechanism for knowledge transfer and gathering feedback on the deliverables
• Project acceptance criteria

Gathering the required information and documenting it is vital for delivering the right value to a client. Image Credit: pmi.org

Though the Agile approach does not place much emphasis on documentation, minimum documentation is required to avoid ambiguity and keep all the stakeholders on the same page.

The documents include:

• Project charter
• Stakeholder register (a RACI diagram)
• Work breakdown Structure (WBS)
• Project schedule
• Change request management
• Lessons learned register

Step 2: Build Your Team

Once you have gathered all the information regarding the project, it is time to build your team.

While building a team to execute a project, you must assess the skills required for the successful completion of the project. And thereafter, you need to rope in the right people with the right skills into the team. If there is any mismatch between the skills required and the skills available, the project is likely to run into rough weather and create innumerable impediments throughout the project life cycle.

Rope in the right talent for the successful execution of a project. Image Credit: pmi.org

To ensure that you have the right talent, you can create a talent and skills spreadsheet and evaluate all the team members before you onboard them.

Document each member’s qualifications, areas of expertise, years of experience, and, most importantly, their proficiency in executing the relevant tasks.

While onboarding the members, you must also ensure that the team members have the required traits to succeed in an agile environment.

Behaviour/characteristics to Succeed in Agile Environment:

• Comfort with ambiguity and changing conditions
• A commitment to excellence and continuous learning
• Pride and accountability for one’s work
• Being receptive to feedback
• An ability to collaborate
• High level of emotional intelligence
• Being self-motivated

Step 3: Create Agile Ambiance

To implement Agile approach, first you need to create a conducive environment. As far as possible, all the members of a project team need to be collocated, preferably in one room, to facilitate easy communication and collaboration. Collocation also builds mutual respect and trust among team members, which improves the effectiveness of project execution.

In a remote work situation, technologies that facilitate collaborative brainstorming, such as Miro, can be used.

If possible, rope in the services of a scrum master to facilitate and coordinate all the project activities. The scrum master should be easily approachable and be able to implement an agile way of working.

Creating an agile ambiance is an important prerequisite to attaining optimum results. Photo by Austin Distel on Unsplash

Any project should be broken down into small, manageable chunks to enable the project team to deal with it in an easy manner. The team led by the project manager must create a road map for the product that is on the anvil. After that, a product backlog should be created that constitutes various features of the product. Each feature should be broken down into Epics (large user stories), and the Epics should further be subdivided into User Stories. And, finally, the user stories are divided into various tasks.

A product backlog is progressively sub-divided into various tasks for easy execution of a project.

Every Sprint takes up one or more product backlog items, usually in the form of user stories, for execution. The product backlog items and the user stories that are taken up as part of the sprint need to be placed on the Scrum or Agile board. The Scrum board should also depict the project team’s progress in terms of executing the user stories.

You might be wondering what exactly is the difference between a Product Roadmap and a Product Backlog. Product Roadmap is a strategic plan that describes how the product is likely to grow over a longer time frame, whereas a product backlog is a tactical tool that breaks down the product development process into progressively smaller chunks, such as epics and user stories. And, an epic is a large user story that can’t be fit into a Sprint. Therefore, epics are sub-divided into smaller user stories to accommodate them into a Sprint.

Here, gaining a thorough understanding of a user story is vital to the implementation of Agile. A user story provides a description of a product feature from an end user’s perspective. It describes the types of users, what they want, and why they want it. Preparation of a user story enables the project team to stay focused on being customer-centric.

How is a User Story prepared?

What?

It describes a feature of the product that is being developed.

Who?

It describes the person who will be using the feature.

Why?

It describes why the person wants to use it and what benefit/value he/she wants to derive from it. This information enables the team to know what is driving the request for the incorporation of the feature.

How to create user stories:

The user stories need to be captured in a specific format. The standard format that is used is…

As a…

This part describes who the user is. Based on the profile of the user, you may design a particular feature that best caters to his/her requirements. For example, you may prefer to design something in a particular manner if your end user is not so tech savvy.

I want…

This expresses what the user is trying to accomplish by using a product or feature. Understanding what the user wants to accomplish is vital to delivering the right value.

So that…

This describes why the user wants to accomplish something, and this piece of information provides the project team with vital inputs. These inputs enable the team to provide the right value through the product or feature.

Step 5: Start Sprinting

Sprint or iteration is the short working cycle where Agile is implemented. It is the most important event in Scrum. The project lead/manager should set short working cycles, preferably one or two-week cycles (Sprints). At the end of each sprint, the project team delivers a product increment, which is presented to the client.

The client, after evaluating the product increment, provides his/her feedback. Client feedback enables the team to know whether they are on the right track or not.

Sprint is at the heart of agile approach. It simplifies complexity and empowers a project team to execute the project in a systematic way. Image Credit: scruminc.com

For example, if your team agreed to have a week-long sprint, they must have a sprint planning session on Monday, and sprint review and sprint retrospective meetings on Friday afternoon. And the team must have a daily scrum meeting where all the team members discuss what they did yesterday and what they are planning to do that day.

The daily scrum meeting should be restricted to around 15 minutes.

At the end of every sprint, a sprint review should be conducted, where the iterated/updated product should be presented to the stakeholders to receive their feedback.

The main difference between the sprint review and the sprint retrospective is that the sprint review is client-facing, where the product increment is presented to the client, whereas the sprint retrospective is internal, where the project team members assemble to discuss what went well during the sprint and what did not.

The project team creates a product backlog, which is a list of all the tasks that need to be completed as part of the project deliverables. The product backlog should be displayed on a scrum board to make it visible/accessible to all the project team members.

There are four events that are carried out as part of every Sprint. They are:Sprint Planning

• Daily Scrum
• Sprint Review
• Sprint Retrospective

Step 6: Organize Sprint Planning Meeting

The spring planning meeting is attended by the project team, team lead, and the Scrum master. In the meeting the below-mentioned topics are discussed.

• What can we deliver during the upcoming sprint to achieve the sprint goal?
• And, how will we deliver that work?

These questions help everyone agree on a goal for the sprint, map out the next one or two weeks of work (or whatever the sprint duration is) and set the team up for success.
Before you conduct the sprint planning meeting, you need to ensure that the product backlog is up-to-date and refined as the team has to decide which backlog item needs to be taken up as part of the sprint.

Step 7: Set Up a SCRUM Board

Before a sprint kicks off, the team has to populate a scrum board with all the tasks that need to be completed as part of the sprint and the people responsible for the completion of the tasks. You can either use sticky notes or a tool such as Miro (in case your team is working remotely). The scrum board makes all the work visible to team members. It also enables the team to better organize its work.

Note: Always make sure that your work completion forecasts for the sprint are realistic; in other words, the workload should realistically match the team’s capacity. And, also, make sure that you prioritize the most important work.

All the work should be broken down into small pieces (work breakdown structure) and the time that is needed to complete each task should be written on sticky notes. All these stickies will go into the product backlog. And, thereafter, the team should discuss and decide how much work they can finish in the sprint they are about to start. Based on the forecast, the team transfers some of the tasks into the TO DO list on the scrum board.

A Scrum Board depicts the product backlog, the user stories that are taken up for the sprint, and their progress. Image Credit: ZOHO

Step 8: Organize the Daily Scrum

The team must organize a daily scrum meeting to facilitate coordination among its members.

During the scrum meeting, each team member should brief the rest of the team members about his/her work.

The team members should typically touch upon the below-mentioned points.

• What did the team members do yesterday?
• What are they planning to do today?
• Are they experiencing any roadblocks in their work?

After every daily scrum meeting, the team members should move the tasks on the scrum board from ‘To Do’ to ‘In Progress’, ‘Completed’ or ‘Blocked’.

Things Needed to be observed During the Scrum:

• All the team members must be present in the scrum meeting
• The scrum meeting is to achieve better coordination among the team members, not just to give their work status
• The meeting should typically last no more than 15 minutes
• The scrum meeting lets the team know how they are progressing and whether any team member requires help

Step 9: Conduct Sprint Review Meeting

The sprint review meeting is where the project team makes a presentation to the stakeholders, especially the project sponsor, about the progress they made during the sprint. The team members should demonstrate product increment (Potentially Shippable Increment) and be ready to answer any questions the sponsor may pose. The review meeting also provides the sponsor with an opportunity to give some feedback about the product increment. The feedback lets the team know whether they are on track to building the right product and are aligned with the sponsor’s expectations.

Step 10: Organize a Sprint Retrospective

The sprint retrospective meeting lets the project team discuss what went well during the sprint and whether there are any changes that are needed to improve the functionality of the team. It also lets the team introspect whether they are producing the right product with the right quality and at the right velocity. The learnings from the sprint empower the team to bring about the required improvements in the next sprint.

A retrospective is a private meeting where only the project team members will be present. The project sponsor is not invited to this meeting. The team members can openly discuss the pain points and learnings during the execution of the sprint.

The team can provide feedback on how things went during the sprint and can even provide some suggestions for improvement. The project lead/manager needs to consider the feedback and suggestions given by the team members and act upon them.

A safe environment must be created during this meeting to enable the team members to openly express their ideas.

Step 11: Watch out for Negative Patterns:

The project manager/lead must be alert to any negative patterns that may derail the project. Some of them are:

• Work is completed even before the sprint is complete, implying the fact that the team hasn’t committed to enough work.
• The team did not complete the forecasted work implying the fact that it committed to too much work.
• The work hasn’t been broken down into small enough chunks.
• Things get added midway through the sprint implying scope creep, which is undesirable.
• The project does not comply with the budget and schedule.
• The final deliverable is not properly tested before release/handover.

Step 12: Release Product & Celebrate Success

Once you make sure that the project meets all the intended goals, especially the customer needs, and proper testing is done, the product is handed over for operations.

The project sponsor and the stakeholder accept the deliverables if they meet the project acceptance criteria.

While wrapping up the project, review all the lessons you learned with the team.

Celebrate your achievements and reflect on your failures. The team must treat all failures as learning opportunities.