Scrum Ho-Hum?
Are you a small business owner attempting to learn about the existing methodologies and project development strategies that go into project management and the on-time delivery of your product?
Well then, have we got the blog for YOU!
Another amazing (at least we think so) blog brought to you by eCodelogic a custom software company with an ecological commitment. Our headquarters is located in Orlando, Florida, but we provide renowned services nationwide.
If any of this does not make sense or if you would like to learn more, please get in touch with us at (407)502-5354. We would be happy to assist you with your business needs.
Now onto the blog!
Calling All Small Business Owners!
Are you bogged down with Scrum ho-hum? Loading one unimaginative, lackluster video after another, hoping for a more straightforward solution of truly understanding terms like Agile, Scrum, Kanban, and Waterfall?
Prepare yourselves! We are excited to bring you something savory and scrum-tious (yes, we did, and you’re welcome)!
Buckle up, because here we go!!!!!!
The Epic Downfall of Waterfall
Before jumping into the gloriousness of Agile, let us take a brief detour down memory lane to learn about the epic downfall of a once widely used and accepted project management methodology called Waterfall.
Thought to represent a tiered model approach, invented by Winston W. Royce, Waterfall involves five steps of linear progression: (from top to bottom…like a waterfall) planning, system build, testing, review, and delivery.
Each of these fives steps required a long, drawn-out process that often had missing elements, which either caused a delay of progression to the next tiered step or even caused a jump back to the previous project phase once progression has already occurred, causing something similar to this:
You see, with Waterfall, project delivery may not happen until many months or even years from initiation. So while you may initially feel like this upon project initiation:
You may feel a little something like this upon project “completion.”
An Unhappy Ending at the Foot of the Falls…But Why?
Many people often wonder what went wrong in their approach. Here are some reasons:
Waterfall Project Management
While considered a more straightforward approach, this method is not ideal for projects that do not have clearly defined planning requirements.
Project Scope: All Your Ducks in a Row
Often, at the beginning of a project requirements stage, there may be many unknowns. This could cause further delays in planning, as the scope and expectations are not clearly defined.
So while the Waterfall approach may work well ideally when the scope is well known, oftentimes, this is not the case. Following the straight and narrow, there is absolutely no wiggle room for change with the Waterfall project management approach.
Large Teams Equal Decrease in Team Member Coordination
With straightforward requirements that are clearly defined upon project initiation, Waterfall is streamlined to work with smaller-sized projects and is documented well to eliminate misinterpretations.
Customer Feedback and Participation
Waterfall essentially gives their customers “the boot” with less customer involvement once the project has been initiated. This approach may risk great disappointment, as the product delivery may not meet client expectations.
Prioritization of Features
With Waterfall, project changes can pose a problem, as making changes in previous stages of the development process can further delays.
Feasibility
Waterfall is not dependent on its feasibility or ability to be carried out in a reasonable manner. This may involve long, drawn-out stages due to highly complex projects.
Project Funding
Development with the Waterfall approach involves up-front contracts.
So, while this seemingly refreshing and perfect methodology, as perceived in comparison to waterfalls, was implemented into real-life practice, it was later realized that this methodology, again like waterfalls, had an unhappy ending at the foot of the falls….or the end of a long, drawn-out project process. The fate would be real and ugly, costing terrible loss!
Sad but true story, but thankfully, there are easier known methodologies that work better for project management and delivery!
…All this talk about waterfalls and thunderslides can bring up quite the appetite! So let us just sidestep, hop, and shimmy on over to our next methodology: the awe-inspiring and delectably appetizing agile approach!
Agile is implemented through two frameworks: Scrum and Kanban methodologies!
So, without further ado, let us get this project started!
The Agility of Agile: The Go-To Approach for Complex Projects and Cross-Functional Teams
While the terms Agile, Scrum, and Kanban are often used interchangeably by cross-functional team members, there are some distinct key differences.
Agile is an iterative development mindset for the project management and software development process.
And It All Began Like This…
Once upon a time (2001) in a far-off land (The Lodge at Snowbird ski resort in the Wasatch mountains of Utah), seventeen tech dudes journeyed from afar to seek common ground on how to deliver value to their customers in a more efficient manner.
Seeking warmth on one bitter night, they sat cross-legged around the fire at The Lodge. During their late-night hand holding, Kumbaya song-singing experience (we are totally stretching the story), they created something quite extraordinary: The Agile “Software Development” Manifesto.
The seventeen tech dudes decidedly made themselves proudly known as the Agile Alliance (they had jackets, fellowship rings, and everything swag to commemorate that moment). Yet, unbeknownst to the sensational seventeen, our super awesome story points not only to the epic name they created – the Agile Manifesto – but mainly to what this entails.
Four Key Values of Agile Methodology
Developed with ideas centered on principle, the Agile Manifesto was founded on four key values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Twelve Agile Principles
The Agile Manifesto also lists 12 principles for software development teams. They are as follows:
- Customer satisfaction
- Early and continuous delivery
- Embrace change
- Frequent delivery
- Collaboration of businesses and developers
- Motivated individuals
- Face-to-face conversation
- Functional products
- Technical excellence
- Simplicity
- Self-organized teams
- Regulation, reflection, and adjustment
This agile philosophy is the cornerstone of the agile community, and this shared vision has proven time and time again that products can be delivered with the mindset that people are continually placed at the heart of the process.
Additionally, the Agile methodology of software development projects can set measurable standards for quality, usability, and completeness. These principles represent the underlying foundation for project management framework methodologies such as Scum and Kanban, both of which will be explained in detail below.
But first! Who is hungry? All this talk of riding waterslides and late-night song singing can bring up quite an appetite!
Join us as we attempt to provide an easy solution for learning about Scrum and Kanban methodologies…through the use of food….where the…end product…will always be delivered smelling like roses…(It’s too late to change the metaphor, people, just work with us).
So, we made it to the nearest buffet, Pam’s Southern Buns All-You-Can-Eat Buffet, with empty stomachs and raging hangry appetites! Our eyes gleam with excitement as we view all the delectable food items within reach. Naturally, and what any reasonably sane individual would do would be to pile everything onto their plate and scarf it down in one second flat, right? WRONG! (Even Karen knows this is a horrible idea).
Just as the concept of how stuffing our faces and bombarding our GI tracts with various food items results in disastrous porcelain throne “outcomes,” project development team members can also be easily overwhelmed by a process with poorly defined goals and expectations, leading to burnout and poor product delivery.
Savor every bite to get your product value worth. If you try to “consume” everything all at once, you will end up wasting money and, quite literally, throwing all your “value” down the John…that’s right, tell me, who hasn’t been in this situation before?
Agile Scrum and Kanban
Two common frameworks, Scrum and Kanban, take the entire project, metaphorically filled with items from Pam’s Southern Buns All-You-Can-Eat Buffet, and break everything down into manageable, bite-sized pieces.
The Scrum framework, a form of incremental development, will be the highlight of discussion, as it is the commonly preferred method of the cross-functional team.
Additionally, we will briefly touch on the Kanban framework, another widely used approach for project management processes.
Ultimately, the goal of Scrum and Kanban is to facilitate the delivery of a product that meets or exceeds customer expectations.
Savory and Scrum-ptious Scrum (Say This 3x Fast)
The agile scrum methodology is a management process framework used by business owners to allow for team collaboration and project work efficiency.
The agile and scrum team focus relies on incremental development. So, instead of building a product from start to finish, as expressed by other process methods, the scrum process delivers several iterations of a completed product in less time and with great value. Each completed cycle of iteration usually occurs in a timeframe of 1 to 3 weeks and is called a sprint. These incremental sprint cycles may be repeated, reducing the amount of timeframe from development to testing.
Upon a sprint cycle completion, there is a potentially shippable product.
Scrum Process Logistics
There are three key roles involved in scrum project management.
Scrum Teams: Pork vs. Chicken!
The scrum team consists of team members that fittingly play into our food narrative. Tasty!
The two sets of roles in agile scrum methodology: are “Pigs,” or core role members, and “Chickens,” or ancillary team members.
“Three Pigs” in Agile and Scrum Methodology
Three core roles are needed to make agile projects run well. Committed to implementing scrum values and scrum processes, these core team members are the Product Owner, Scrum Master, and Scrum Team.
Product owner
The product owner is often represented as a stakeholder vested in the product and is typically the customer. As a way to ensure that the scrum team is delivering value to their business, the product owner is responsible for defining the features for the product and coming up with the vision and bright ideas that turn into products for the end user. They are the key players in self-organizing and prioritizing goals for each sprint cycle.
Scrum Master
Scrum principles are deeply instilled in the Scrum Master, a servant leader with the responsibility of safeguarding the entire team, running meetings, and keeping everyone pumped!
Scrum Project Team
The “Third Piggy” core role classification of Scrum project management is the Scrum team. These scrum teams often are made up of developers, writers, testers, and anyone that is involved in the creation of the product. The team members collaborate to get the work completed within the allotted timeframe. There is a sense of ownership and team responsibility when frequent communications are made between the team leader and others working on the project during daily scrum meetings.
The “Chickens” – Ancillary Roles
Ancillary roles that take part in the scrum project include other customers and executive team members who are involved for the purpose of consulting, summarizing progress measures and collecting feedback to deliver products with the highest value.
Three Scrum Artifacts
There are three scrum artifacts, or documents, used in the scrum framework: The Product Backlog, User Stories, and Burndown Chart.
Product Backlog
The product owner, the visionary with bright ideas, creates a list of features (called user stories) that could go into the development of the product and prioritizes the list to share with the scrum team.
User Stories
User stories are a way for the product owner to provide just enough detail for the team to assess the size of a given task. Describing the feature set may include a phrase format to allow for an easier and more effective way to communicate.
All user stories that are marked high priority are then added to the sprint backlog, which are listed items for the next sprint.
Burndown Chart
As the software development team demonstrates positive progress, the burndown chart is used as a visual depiction of every task completion of sprint backlog items. Upon sprint completion, the burndown chart would approach zero points.
Three Scrum Events/Ceremonies
Scrum ceremonies can be thought of as special meetings or discussions by Agile teams.
Sprint Planning Meeting
The product owner, scrum master, and development team members meet to deliberate on user stories from the sprint backlog and assess task sizes.
Daily Scrum Meeting
This meeting is performed daily where the project manager and team members discuss the task items from the sprint backlog that have been completed since the previously held meeting, the status of current task items, and any outstanding work that may be blocked from completion and in need of assistance.
Sprint Review and Retrospective
The sprint review and sprint retrospective meeting is held at the end of each iterative sprint cycle. During these meetings, the team would demo the completed tasks to the product owner and brainstorm ways to improve the process for future sprints.
Here is a Rundown of the Entire Scrum Process
Product Backlog
The product owner is the brains behind the outfit, listing all the bright ideas and pulling all the user stories into the product backlog. All user story points are prioritized and brought to the project manager and team members for review.
Sprint Planning
The complex project is reviewed by the product owner, scrum team, and scrum master, and all tasks and user stories are assessed and prioritized into the sprint backlog.
Sprint backlog
Output from the sprint planning meeting is placed into the sprint backlog. These items will be committed for the next sprint.
Sprint
During the sprint, which occurs from one to three weeks, daily scrum standup meetings are performed where the team reviews and discusses all the tasks they have completed and any blocked items that impede on project progress.
The outcome of every sprint is a potentially shippable product, which is determined by the product owner on whether product delivery is warranted.
Sprint retrospective review
Upon iterative sprint cycle completion, the scrum team demonstrates the product to the product owner and other stakeholders. During this meeting, a retrospective discussion occurs where the team leader and members brainstorm what they can do to improve their process for future sprints.
This process is repeated for each sprint.
Kanban
Kanban is also an implementation of agile methodology with a similar framework as Scrum. While there are similarities with Scrum, such as the inclusion of a product backlog, daily standups with the product owner, agile coach (similar to the scrum master), and development team (like the scrum team), the Kanban framework has a few key differences.
Kanban is a continuous process, where items from the product backlog are pulled and placed onto a Kanban board (or sometimes referred to as a Scrum Board) containing Build, Test, and Done columns. Each column has a strict Work in Progress (WIP) limit, ensuring items move from one column to the next, in the shortest possible time.
Nearly empty columns signal to “pull” an item from the previous column. This is called a pull system. Once the product successfully moves completely across the board, the item is released the moment it is ready.
At the close of the Kanban process, and similar to the Agile Scrum approach, there is a product demonstration to the stakeholders and a retrospective with the development team on what went well and how the process could be improved.
So There You Have It!
You have successfully arrived at the conclusion of our wild yet highly entertaining blog on the discussion of Waterfall and how that methodology has transitioned into the Agile approach, a methodology implemented through Scrum and Kanban-style frameworks. The goal of the Agile Scrum methodology involves the delivery of products with frequent continuous customer collaboration, utilization of high-efficiency practices, and product delivery in a decreased time frame. A customer and team collaborative process with a reflectance on core values that is a brag-worthy mention of the agile philosophy leaves no wonder that previous traditional project manager practices are increasingly being replaced with agile methods.
More and more teams and project managers in the software industry (and any type of business, really) are adopting agile scrum methodology practices and standards for a customer-driven process that leaves everyone with an end product smelling like roses.
Conclusion
We hope you enjoyed reading our blog! Please reach our office line at (407) 502-5354 to speak with a member of our eCodelogic team, or visit our website at www.ecodelogic.com.