Reduce your risk, reduce the capital required to start, and get to market faster. Since the '90s, Agile Scrum has become increasingly prevalent in software development because it creates a method to successfully cope with loosely defined and constantly changing requirements.
Agile Scrum is an iterative software development methodology specifically designed to build products faster. Agile Scrum uses short pre-defined development cycles (called sprints or cycles), with each cycle resulting in potentially shippable functionality delivered.
Would you like to use this graphic in a presentation or training? Feel free to do so under the following creative commons license.
How does Agile Scrum reduce your risk?
Other development methodologies require you to define and scope the whole project before you can begin. We are able to get started right away. As soon as we know enough, we can build. Then we add on as the details become more evident.
Early Results Delivery
Feedback is key in this process as it determines the next few steps. We schedule regularly occurring demo meetings where we show you exactly what was worked on and have your stakeholders play with it.
Things change – unlike a traditional Waterfall approach, Agile Scrum is geared to handle scope change – at the start or at the end of the project.
Showing your working software budget regularly allows you to have peace of mind that things are on track.
We work with you to develop and maintain a list of all the items/features needed for the specific project. You may choose to break a project into phases, in which case the upcoming phases act as your roadmap.
Faster Time To Market
Our process aims to develop a minimum viable product (MVP). We want to get something done fast and get it out there for feedback. The sooner you get feedback, the sooner you can decide to change things or feel comfortable with your decisions.
How does Agile Scrum Work?
We are going to focus on the agile process using the scrum framework. The agile process is really quite simple once you understand the essential components. Unfortunately, the water does get a bit muddy when talking about different agile methodologies, so let's concentrate on scrum, which is the most popular.
The process starts with a product owner creating a prioritized product backlog. Product Owners manage the product backlog and ensure the company gains maximum value from the product. The prioritized backlog is actually one of the most understated features of this process. Too many companies start a development project by trying to outline every single thing that has to go into this application or software. They often fail to realize that a large percentage of the features may never be used, may never work correctly, or may just waste valuable time and dollars.
A backlog is comprised of stories in the story the product owner describes "who" will be conducting the operation, "what" they will be doing, and "why." This gives great insight and clarity to the programming team. By creating a backlog, the product owners essentially make a list of the dreams and wishes in story form. Then the product owner organizes the backlog in priority order, with the most important items at the top and the least important at the bottom. Now this list and priority can change after each sprint or iteration. The goal here is to focus on what brings value to the business and not on what we would like to have.
The process is all driven by the prioritized product backlog you just described. The product backlog is the input necessary for the sprint planning meeting.
Sprint - a short time-boxed period
"Sprint" is a term used in the scrum framework to describe the basic unit of development time. In most cases, it will be from one week to one month in length. A project or release is usually made up of several or many sprints. Getting back to the sprint planning meeting, the purpose of the meeting is for the team to commit to the amount of work they can complete during the sprint. The work is roughly sized using one of several different agile estimation techniques allowing the team to determine the proper amount of work for the sprint. An important point here is the team isn't just doing this as a guessing game it is much more disciplined than that. A team has a velocity or amount of work per sprint which, over time, they know to be accurate.
Good teams will never commit to more than their normal velocity they also recognize the importance of the priorities in the product backlog and will always work on the highest priority items which will fit in the sprint. This gives the customer their highest priority items and, therefore, their highest value as early as possible. Once the sprint planning meeting is completed, the team starts the actual work.
Each day during the sprint, the team gets together for a short meeting lasting 15 minutes or less called the daily stand-up meeting or daily scrum meeting. During this meeting, team members tell each other what they have completed since the last meeting, what they intend to complete before the next meeting, and whether they have any impediments which may cause them to become blocked. The team uses this time to determine how best to share information to help each other to complete their sprint commitment. This short meeting exposes risks and knowledge to be shared, which in turn helps the team be more effective.
The Scrum Master
Up to this point, we haven't mentioned the role on the graphic called "Scrum Master." The person filling this special role is responsible for helping ensure the success of the project they remove impediments for the team, help the team make responsible decisions and basically support the team in any way possible. This role touches all areas of the organization while representing the team and is usually vital for team success. During the daily stand-up meeting, this person will likely note any potential impediments and immediately begin working to ensure the impediment won't be a problem.
While the Scrum Master and Product Owner work together, these roles are very different. Product Owners manage the product backlog, including requests and priorities, and ensure the company gains maximum value from the product. A Scrum Master leads the Agile development team and supports the Product Owner by relaying updates to relevant employees.
Sprint Review / Demo Meetings
At the end of the sprint, usually on the last day, two other meetings are held the first is the sprint review or sprint demo. The sprint review or sprint demo is important for many reasons. First of all, it shows the product owner and client what the team accomplished. They already knew what we were going to work on, but now they can see the results firsthand. They can also provide feedback based on what they see. Maybe the development result actually made another story unnecessary. Ultimately the client can now see the requests progressing.
Some development companies go into what we call "the cave". They develop features and write code for months and come back with a finished product that looks nothing like what the client wanted. By doing sprint reviews and demos, we can mitigate that risk and deliver exactly what the client wants.
The final piece of the process is a sprint retrospective. Like the sprint review, the sprint retrospective has one main purpose. In the case of the sprint review, the main purpose is to improve the product. While the sprint retrospective's main purpose is to improve the team in the process. This core principle of continuous improvement is one of the things which makes scrum completely different from other development frameworks. Many people have been in lessons-learned meetings and then immediately forgotten all of those lessons. Sprint retrospectives bring up successes and failures, and during this meeting, actual action items are created to help the team improve how they work. Improvements can be in areas ranging from logistical things like the arrangement of team members in a building to better use of automated testing tools to help ensure product quality. The improvements often aren't simple, but they are continuously worked on and updated each sprint. The sprint retrospective empowers teams to be successful by allowing them to work on improvements each sprint. These improvements are not driven by managers but by the team taking pride in their work.
Rinse and repeat
At this point, if the product is completed, it will be released. However, normally once the sprint retrospective is completed, the team cycles back to the beginning of a new sprint, where they begin with sprint planning.
A very important part of the process is the "finished work"; the wording is the important thing here. Finished work means it is a piece of the product that has been completed and is functional. In other words, in every sprint, the team will finish work that has some value and is truly completed it allows working software to be demonstrated, and if enough working software has been completed, it may allow for an early product release. It is not uncommon for customers to say something like wow, can we get that now because it would be really useful today. Using scrum allows a team to actually say yes.
Reporting At A Glance
A common report utilized in Agile Scrum is the burn-down chart. A burn-down chart shows the amount of work remaining on a project (the remaining effort), whereas a burn-up chart shows how much work has been completed and the total scope of the project.
Want to learn more about Agile Scrum and have 8 minutes and 2 seconds?
Here’s a video explaining Agile Scrum and how we utilize it for web development and mobile application projects.