Building great products require great ideas along with a well thought of plan of execution. Project Management Trends in 2020 requires a great sense of thought and nurturing which directly correlate to the success of the project and accomplish the vision. There is no one solution meets all when it comes to project management. Let’s look at 3; Agile, Scrum and Kanban.
Over the years, there have been many trending project management strategies; which various companies have used to successfully deliver software projects. 2019 had been no exception. With insurgence of edge computing, multi and hybrid clouds with machine learning and artificial intelligence becoming core of the products; the project management strategies had to adopt newer strategies and efficiently devise plans which create lesser interdependence among cross-cultural teams.
Before listing these trending strategies, there is an important difference to note about what comes in project management vs product management. Product Management refers to the aspect of deciding what’s right for the product. Project Management refers to what’s the right way to efficiently deliver the product features based on the product goal. Below are a few project management trends that you can no longer ignore when stepping into 2020.
Agile Project Management
Agile project management has been the erstwhile leader in project management over several years. It continues to reign the league in 2019 as it is the most common way used to build software and Cloud Based Services applications. There are critical benefits of using Agile. It helps stakeholders, product owners, scrum masters, engineering leads, developers, testers and DevOps Services to stay aligned and achieve product goals set forth.
Scrum-based Development Model
The most common Agile process uses Scrum based development model which typically consists of Sprints with a defined goal to achieve in 2-3 weeks. Typically the stakeholders and product owners define the goals to achieve in a Sprint based of which EPICs are created. EPICS are issues which deliver new value for the end user and usually to accomplish that requires collaboration from different components owned by cross functional teams/members.
Setting up a new click-stream capture requires Business Analyst, DevOps, Developers and Testing efforts.
The Scrum master sets up user related story based off this EPIC and assigns to different teams for work. Scrum master/Engineering manager typically heads the Sprint. They will take approvals/feedback from product owners for changes of scope of the Sprint/EPIC. The Engineering Manager would be responsible for delivery of the items in the Sprint and get the User Acceptance Testing completed.
There are several Sprint ceremonies which the Scrum Master conducts in the process.
1. Sprint Planning
- This is scheduled to be conducted on Day 0/Day -1 of the Sprint.
- The objectives of these meeting are to define Sprint goals: what stakeholders would like to achieve in the next Sprint.
- In the Sprint Planning meeting, all developers will look at the tasks; estimate the time needed for accomplishing the tasks and confirm to stakeholders what can be achieved and what need to be moved to next Sprint or prioritize accordingly to fill in the Sprint capacity in this Sprint.
- All tasks need to be tagged with a version number using semantic versioning. If a story/epic takes more than one sprint to finish; then we need to tag it to the next upcoming versions.
2. Sprint Demo
- This is scheduled to be conducted on the Day 8 of the Sprint. If Day 8 is a holiday, then it will be on Day 7/Day 9.
- Developers or Engineering Manager would give a demo of all the features which are developed in the Sprint in a call to product stakeholders. Stakeholders can comment on what is good and what is expected to be better. Show how competitors are working.
3. Sprint Retrospective
- This is scheduled to be conducted on the Day 10 or last day of the Sprint.
- The goal of this meeting is to:
- See what’s achieved and what can be done better.
- Identify bottlenecks and figure out solutions to do it better.
- Stakeholders can give feedback on the performance and expectations for next Sprint.
There are a few issue types that can be used in a SCRUM based development model;
- EPICEPIC shall be used for a major feature/initiative which shall span across different components and possibly multiple Sprints. These usually align with the quarterly goals for the organization. An EPIC contain multiple stories. Each EPIC must have an acceptance criteria specified.
- StoryStory shall be used for a new development task for each component. Each Story should shall also have acceptance criteria. Each story shall also have an estimated time and estimate effort filled in.
- ImprovementThis ticket type shall be used to improve an existing functionality. Each improvement should shall also have acceptance criteria. Each improvement shall also have an estimated time and estimate effort filled in.
- BugThis ticket type shall be used when functionality in the app and web is not working as expected. Each Bug shall have a description; steps to reproduce; Expected Result and Actual Result. The bug shall be approved when the Actual Result is accomplished in the dev-release.
- TaskThis ticket type shall be used when there is no code to release for the activity to be performed. This is usually for maintenance tasks, setup tasks or research tasks. DevOps tasks come under this category usually.
Scrum based development is ideal when there are multiple teams working in tandem and the team is expected to move with a certain velocity. There are several reports which are used to perform the measurement of Sprint. One important measurement is the Sprint burn-down chart which tells the remaining estimate vs actual estimate as the Sprint goes from beginning to the end. This type of development process is also useful when there are regular feedback to be given by the stakeholders and the requirements are often changing. The requirements often get change Sprint over Sprint.
Another important aspect of Scrum based development is that the Sprints and releases can be handled independently of each other. Each Sprint does not necessarily need to have a release associated. A release can be part of a Sprint task to achieve a business requirement. A task can be worked in a Sprint which can last for more than 2 releases or which is in a release a month from now.
While Scrum based development is used for iterative timed development with an expected velocity, Kanban Development process is used when the tasks go though a set steps in a workflow. Kanban is ideal for support projects and projects that don’t have a fixed timeline to achieve the project deliverable.
In Kanban development process, a workflow is defined with different status. There are only a set transition process. The tickets are usually prioritized in order of importance. The developer/participant takes the ticket with the highest priority and works on the task and finishes it to completion. Once the ticket is completing or waiting on feedback on anyone else, the developer/participant will pick up the next ticket. The ticket states are usually organized from left to right and the ticket move from left to right. The tickets are capped by number in each queue. For example, for a team of two only 2 tasks can ever be in progress. Similarly, we can max out the number of tasks that can be in the queue per status.
The workflow is defined as per the requirements of the project It is a common misconception that the workflow should be simple with 4-5 steps in the process. But, it is not necessarily true. The flow can be defined as per the project requirements with feedback and request loops for the ticket. The major difference between the Scrum and Kanban boards is that time and velocity is not off the essence in Kanban as it is in the Scrum based model. However, Kanban based projects have some general expectations and a Service Level Agreement of resolution time is set by consideration between two parties. However, this is a more relaxed agreement as the capacity of developers is not planned in advance and ad-hoc.
These type of projects are good for teams who are staffed in ad-hoc fashion with no prior capacity planning and with a plan as you go approach. The releases in this process can be done individually per ticket. However, there have been adopted implementations which releases code every 1-2 weeks in a periodic manner.
The Sprint process is a five day process for answering some critical product questions through prototyping and evaluate ideas with end users. This process is used when a new product direction is to be evaluated or an innovative new product is to be developed by a team. The Sprint process requires undivided attention from all stakeholders, decision makers through the period of 5 days.
The Sprint process is often confused with the Sprints in a Scrum based development. These two are different. The process is lot more focused and is very intense process though it lasts for five days. Typically, the product owners decide on a problem area and the team considers 10-12 ideas and then use a decision criteria to select the best solutions. This process is usually done individually without a group. The prototype gets built during this five day process and on the final day the target customers test the prototype and the feedback is relayed onto the team.
The deliverable for this process are: customer insights generated through prototype. The prototypes can usually not be sold directly. However, they shall be in decent shape and form which shall entice customers to express interest and ask for a purchase for which pre-orders can be taken if necessary.
The process starts on a Monday and ends on a Friday. Below are a few things the teams or a business unit need to iron out before deciding to start on a Sprint.
- Define a problem statement to solve in this 5 days. To stipulate this for an existing product, a thorough analysis of user behavior metrics needs to be done and the customer pain points shall be jotted down. After that, the ones which create most impact and the ones for which the solutions are a big unknown shall be prioritized and a few top problems shall be picked to be run through the Sprint process. For a new product idea which is a ground-breaking evolution, the problem statement would be to evaluate the most prominent value proposition the product brings to the customer and has scope to generate business revenue.
- Define a target customer segment and get an association in place to test out the products once they are ready in the Sprint process. These customers should ideally consist of those who would be ready to pay for the product; should the product solve the problem for them. For free-mium products, the customers should ideally be those who would be the power users of the application.
- Decide who needs to be on the Sprint. The stakeholders shall decide who needs to be on the Sprint. If a business unit is smaller in size with 15-20 people; it is recommended all of them are on during the process and each of them would have a significant role to play. If the business unit is much larger say around 400-500 people; then it is ideal to have select an expert performer and decision maker from each sub team so that the ideas can be evaluated and the process can move faster. All stakeholders of the organization needs to be involved in this process. All key decision makers like product owners and product managers also need to be available. For web and mobile products, a designer or UX expert is also essential as they will help prototype faster using graphic design tools. Having a full-blown team is quintessential for the Sprint to run since decisions have to be made faster and the decision shall also be backed with data.
Once the above things are ready, a week of Monday through Friday shall be selected and the participants shall be given a notice to participate. Here’s a brief into what happens from Monday(Day 1) through Friday(Day 5);
On Monday (Day 1):
- The team shall get together and know the importance of problem statements and evaluate all the ideas each person has to improve the customer satisfaction and make it easy for the customer to achieve the value proposition put in place. For example; if you are building a Cloud Governance Platform to help customers use multi-cloud environments for their enterprise and manage the enterprise level security policies; the team shall look at the possible sub problem statements to achieve this and select the ones which are easiest for the customers to use and define their security policies and figure out a way for them to deploy and choose their app within minutes.
- Then the team shall lay down what are the biggest risks to achieving this solution and getting it right for the customer and attain customer delight. If they get it wrong; then they would face lot of questions and customer disinterest. Probably, the customers won’t even get back with feedback if the solution is not solving their problem.
- An important point to note is to give customer a product which does work. Whatever the prototype does it should still do it well with good design and UX. It can just be a subset of what all the product can do. But, impose to the customer the value this product brings. If customer delight is not coming, then we disappoint people and the product/idea gets sunk.
On Tuesday (Day 2):
- On Tuesday the team would switch to finding all probable solutions to the problems they decided to address on Day 1. The team would analyze the solutions; sketch them. These paper designs or power-point slides are not done just by designers but every person on the team including the stakeholders, CEO etc.
- At the end of Day 2, the deliverable are to get a consensus of what are the solutions they would like to test. The teams shall use a criteria to evaluate these solutions. Often times, there would be much discussion on which idea is best; but the decision makers shall put across the criteria which will be used to evaluate the solutions. Every team member then can follow the criteria to do a pre-evaluation of the solutions they are proposing.
- The set of solutions are delivered onto Wednesday and the teams will be waiting on Wednesday morning to do the most important work of this process; which is to evaluate the solutions.
On Wednesday (Day 3):
- The sketches and solutions are plastered on the walls or the whiteboards. There usually are many competing solutions to the same problem. Typically, it would take several weeks/months to get through these solutions in emails and Slack. In this process, the goal is to evaluate and decide on the solution by end of the day. This is the most prominent benefit of this process as it helps the teams get to a decision faster and they can move ahead with it.
- Teams typically use a voting and structured decision process to decide quickly and without too many arguments. These processes are defined on Day 2 already so it would make it much more easier.
For Example: If you are building a Cloud GovernancePlatform, the decision criteria would be: which is the fastest; easiest way for customers/users to get their application/platform running on the cloud. It is also ideal to test solutions which have the biggest risk too. It is an ideal time to take risk.
- At the end of day, the test with the customer will be well-defined and the developers and designers would be gearing to their busiest day of the Sprint which is Day 4.
On Thursday (Day 4):
- As Thursday arrives the team usually have eight hours to get the prototype ready for the live test which happens with the customer on Friday. Eight hours are usually very short to actually build a prototype from scratch. But, these ideas are also generally based on some work which has been earlier.
- So, the teams shall be smart in reusing the solutions which they pre-built in other projects or for different set of customers. It is also okay to copy or adapt an open source solution and just hack it up to create good customer value and evaluate the solution
- The solution also don’t need to do everything autonomously as the end solution would do. We can also look for what the customer would intend to do and present the users with a screen that it is processing. While that is in process, the team can come up with something on live and prepare a response saying that the request is in progress and they can check back in few minutes. In few minutes, it can be displayed to the user that the process is completed either with a notification or an email or a text message to drive user back to the application.
- At the end of Day 4, the solution shall be ready. It possibly has been tested by stakeholders quite a few times. The whole team shall wait for Day 5, the evaluation day which is the most exciting day which the teams look forward to and have worked so hard for.
On Friday (Day 5)
- This is the D-Day where the live test happens. The team would post the solution in front of the customer and they will take it onto the next step of evaluating it.
- As the customers test the solution, the teams will be on back-end evaluating what the customer is trying to do and once the customer sends a request; they would start working on a solution to the request and serve it manually. As discussed in the last section, not all work is automated.
- The customer delight is measured based on how the customer reacts in a feedback session. The customer can also be presented with a feedback form where they can put in their thoughts on how it went.
- If more customers are delighted than disappointed, that means your solution is fitting a core problem for them and you have a great business opportunity to build on. If customers ask or click on Pay/Buy button, it will still be a great value proposition for the user; since he has attempted to check the pricing for the same.
- On Day 5, if the Sprint is successful, you will ideally walk away with some pre orders or letters of intent/expression of interest.
Each process have their own usage and applicability based on the problem you are trying to address for the end user. The product owner/managers needs to make a decision based on which one benefits the user. The Sprint process, if successful gets handed over to the Scrum development process to build the entire product in a lean and iterative process.