Project success with the Agile Approach & Scrum Method
The Agile and Scrum method represent the current thinking in Project Management for projects that require collaborative, fast-paced solution design and build. Get the details on how to use the Agile method and Scrum processes on your next Project.
This article is part of the Project Management Fundamentals Series.
Why is the Agile Methodology important for Project Managers
The agile methodology addresses the challenges faced by the "waterfall" model. In the waterfall model, the process is focused on and design, build and then test format. This means the client may take months before they see a workable outcome and may reject it. This causes wasted effort by the project team and costs for the Project. Agile is the approach for the future for many business situations.
Many large companies use Scrum for their project development, such as Google, Apple, Facebook, Airbnb, Yahoo, Spotify, and Adobe. They use this methodology to complete not only software development but many other kinds of projects.
What is the Agile Methodology
This methodology is an approach to product development associated with the rules and principles based on software development. The agile methodology focuses on delivering the right Product to the customer. This is done through progressive product releases with new functionality (think application development upgrades on your phone).
The Agile Declaration:
The agile declaration is a statement of core rules and principles for the agile software development process. Established in 2001 for software development, it provides 4 core rules and 12 principles that guide people in agile software development.
4 Core values of Agile Declaration:
People and communications regarding processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Acknowledging change over following a plan
Key Agile Methodologies:
Agile is an approach that can work with several methods. Some of the most popular methodologies are listed below:
Scrum
Extreme Programming (XP)
Adaptive Software Development (ASD)
Dynamic Software Development Method (DSDM)
Feature Driven Development (FDD)
Kanban
Behavior Driven Development (BDD)
Because of its popularity and the variety of use cases, the Scrum method will be the focus of the detailed review.
How Scrum Works
Scrum is an agile development methodology used where iterative and incremental processes take place. Agile Scrum methodology is a framework that is fast, adaptable, flexible, and effective. This method fits projects best where customer-based design can be prototyped and interactively tested for results. It may not fit projects that have significant regulatory or documentation requirements.
The benefits to the team are using a process that allows for autonomy and focuses on the outcomes.
The benefits to the client are close cooperation with a team that tasks responsibility for results, values transparency in communication, and shows continuous progress.
Scrum Methodology:
We can say that Scrum, first documented by Harvard Business Review in 1986 and used by companies like Honda and Toyota, has evolved to become a leading approach to Agile project management.
The development process begins by defining the product characteristics that the customer wants to achieve. Those characteristics are then prioritized into order, also called product backlog.
Scrum works in the temporary block called scrum sprints. These sprints are short (generally last from 2 to 4 weeks). Each scrum sprint is considered an entity in itself that provides a complete result. It produces a version of the final Product that must be delivered to the customer.
The Product is developed and understood in the form of a story. The story summarizes a "use case" in human terms.
What is the user's problem?
How will the solution solve the problem?
What are the users end to end experiences, including this new solution?
What inputs, throughputs, and outputs are needed to complete this experience?
See an example of how user experience can address these questions in the video above.
Scrum Team Roles:
The owner of the scrum project continuously defines what the Product should and must have regarding characteristics. He also shares the needed scope (what to do and what not to do) and what order it should be built. He works to overcome any obstacles that can hinder the project progress and task of the development team.
The Scrum Master leads the team and guides the team. This role ensures the team follows the rules of scrum methodology. They resolve the project impediments and work with the product owner to increase the products Return on Investment. The Scrum Master is in charge of keeping Scrum up to date, mentoring, providing coaching, and training the teams if necessary.
"It is the Scrum Master's job to guide the team toward continuous improvement – to ask with regularity, "How can we do what we do better?" – Jeff Sutherland
Product owner (PO): This role represents all the stakeholders and customers who will use the final Product. This person's main focus is on the business outcome. They translate the vision of the Product to the development team. They regularly check and validate the stories' benefits to incorporate them in the product backlog and order them into priorities.
Stakeholders/Users: These are the people who want and need the Product. These people can be the Product's end-users, product testers, or anyone who wants or needs to use the Product is a stakeholder in the Product. They coordinate with the product owner to develop stories, which the team uses to develop the product.
Team: A team comprises professionals, including the designers and developers working on a project who create the product based on the stories for each scrum sprint.
The Sprint process
Project Initiation (Sprint 0):
Sprint 0 is not the scrum principal. So do not use it to fall back into the waterfall development model to design the applications or gather any data knowledge. But having said that, it's been used successfully to do many things such as;
Set up an initial architecture for the developing team to start from the developing ground on day 1 from sprint 1.
The initial architecture includes development, quality assurance, test environments.
To identify initial product backlog or to-do list, so the prioritization process goes well in sprint 1.
To schedule all ceremonies.
To prepare the initial design that can be the foundation of the first stories but can be added to or refactored as development progresses.
Here are some tips that will help you get started:
Choose your Tools:
Select the right tools for team collaboration. Make sure the tools match your project needs. I have had a very good experience with Scrum boards, Jira, Wrike, and cardboard. Need tool ideas? Check out this video.
Define what Success looks like:
Build the right ‘use case’ stories based on the user Persona and Design Thinking workshop. Get more on these processes and free templates to run your workshop and more here.
Facilitate a Project Initiation Meeting:
Complete the project agreement by having the team involved. This includes;
Defining the definition of done: You need to inform everyone what needs to be accomplished to be considered done and exit the sprint.
Defining team agreement: What are the rules the team will follow? Set up the team for success by confirming the team's self-organizing model and clarifying what success for the Project looks like.
Plan Sprint Ceremonies:
Initial backlog grooming (story mapping): Do this at the start of the Project or at sprint 0
Sprint planning: Repeat the first day of each sprint, 1-hour box per week of the sprint (2 hours of standard 2-week sprint)
Daily Scrum/Standup: This repeats daily during the sprint, a time box of 15 minutes. Add 16 minutes to any interaction or additional conversation and dismiss all unnecessary members from the meeting.
Backlog grooming: Repeat 3 days before the last day of each sprint, a time box of 1-6 hours depending on the needs/issues of the stories.
Sprint review: Repeat the last day for each sprint, a time box of 1-2 hours
Sprint retrospective: Repeat the last day of each sprint, one hour box
Conduct initial backlog grooming sessions:
Create a backlog with at least 2 stories if possible. The stories should be complete enough to design and build from, and the backlog should be solid. Then prioritize the stories, and the development team estimates the stories.
Start Sprinting:
Day 1: Sprint Planning:
Developers work and commit stories until you have enough for the team and right according to the priorities of the owner or stakeholders. After the first sprint, the team will use the normal velocity to show their commitment to the sprint.
You can determine the total capacity by knowing the available hours from each team member and then subtracting the time required for all the ceremonies during the sprint. For example, if 4 developers have 40 hours available each week, it means 80 hours for a two-week sprint. Then subtract the time needed for daily stand-ups, sprint planning, backlog grooming, sprint review, and sprint retrospective time to get the actual hours to complete the stories. In simple words, subtract 12 hours from each developer time then the total availability becomes 68. Now multiply 68 by 4 to get the total capacity.
Daily Scrum/Standup and 16th Minute:
The team meets and informs about what they did a day earlier and now what they're about to do. This is an informal meeting and more for collaborative purposes where reliance and communication are needed to self-assign stories. Keep in mind that nobody is telling other team members what to do here. They just meet to ensure everything is aligned and accomplish all the stories by the end of the sprint.
16th minute: This is an extra 15 minutes to discuss the challenges and work together if needed. This doesn't require the whole team to be present. Only the pertinent personnel will attend it. This is not essentially a scrum principle, but it is used widely and effectively in the shortage of time. Well, you need to be skilled to be very politely excusing unnecessary people from the meeting.
Backlog Grooming: 3 days before the end of the sprint
Keeping a backlog of stories created by Product Owner and work to Prioritize stories based on scope.
Asking questions/clarifying requirements: The developers should ask everything required to accomplish the stories according to the product owner's requirement.
Estimating stories: Using test case scenarios can help the team in getting all the requirements clarified.
Most importantly, give the product owner enough time to answer all the questions before sprint planning.
Last Day - Sprint Review and Retrospection:
Review: The team will demonstrate the stories to the product owner to get initial feedback from an important stakeholder and estimate the development's future impact. They should have something like data and maybe visuals of the new feature to show to the owner.
Retrospection: The team in this phase will determine what they have to do, stop doing and keep doing considering the sprint. Reflection at the end of each sprint makes it easy for the team to make any required improvements. Significant differences in product quality, management of the process, and performance can only occur in 2-3 sprints (as short as 4-6 weeks).
It would help if you tried to get as much feedback as possible about the Product to succeed as a team.
Rinse & Repeat:
After you complete the current sprint by using the above-explained scrum methodology, you should start the process from the beginning of the next sprint.
The agile development methodology is now fast and very useful for a variety of project management approaches. Scrum is one of the key agile methodologies that is so far a fast, flexible, adaptable, and yet effective method of product development.
Happy Sprinting!
I hope this article was useful for you. If you liked this article, please don't forget to share it with others and please let me know if you have any suggestions regarding topics, information, article length, etc. Your comments are important to me, so please feel free to leave one.
Thank you for your time.