Ultimate Guide to Agile Methodology – PART 2
If you’re unfamiliar with agile software development…
Take a few minutes to brush up on PART 1 of this 3 PART series: Agile Methodology for Software Development – PART 1
So if you think you need to review, do so now.
Because here in PART 2, we will be exploring the Scrum framework and practices that are going to help your team excel in agile development.
While if you’re already familiar, get ready to learn how to start or improve the way you and your team tackle agile software development with the Scrum framework 🙂
Project management, made simple.
Write software requirements, define priorities, organize tasks, get progress insights- all in one platform.
🚀 We’d love to learn more about your team and the challenges in your current workflow. Let’s chat!
Introduction to the Scrum Framework
The Scrum framework is the most widely used of the different agile practices.
In fact, a recent survey performed by VersionOne shows that 68% of the more than 20,000 people reported Scrum and Scrum/XP Hybrid to be their methods of choice.
If you’d like to take a look at the VersionOne report, you can do so here: State of Agile Report
Consequently, we’ll be referring to the Scrum framework when discussing the practices of agile software development throughout this article.
The Scrum process is relatively straightforward
Scrum is very popular because it provides just enough framework to guide teams, while giving you the flexibility in how to execute.
Furthermore, Scrum concepts are simple and easy to learn.
Teams can get started quickly and learn as they go.
All of this makes Scrum a great choice for teams just starting to implement agile principles.
There’s a product owner, who is responsible for defining the target audience and what their values are, as well as a vision for how to deliver or improve a product or service.
The product owner works with the team to define a Sprint Backlog of user stories that aim to achieve his or her vision.
Each user story defines what is being worked on, for whom, why it’s important, and what constraints the solution must consider. Writing user stories is an important component of product development, especially when you create design documents.
If you are wondering what software design documents are, check out our How to Write Software Design Documents blog post for examples and templates!
Understanding Sprints in the Scrum Framework
A key learning from life experiences, is to break-up a problem into small pieces, and then go about solving each problem.
The Scrum framework does the same thing…
Breaking up product development into small goals (a.k.a. Sprints) and then running cycles to achieve those goals.
So what is a Sprint?
Scrum Sprints
A Sprint – also known as an iteration – is a short period in which the agile development team implements and delivers a specific and potentially publishable application increment.
For example, you may perform your first 2 or 3 Sprints in order to reach your first milestone of a working prototype which performs the application’s core function.
Therefore, you may choose not to publish or release the application to early adopters after your first couple Sprints, but then choose to do so once you have a working prototype.
Scrum Team Roles
Product Owner
The Product Owner is responsible for what the team is building, and why they’re building it.
In addition, he or she is responsible for keeping the Sprint Backlog up-to-date and in priority order.
Scrum Master
The Scrum Master is responsible for ensuring the scrum process is followed by the team.
They are constantly on the lookout for how the team can improve, while also resolving impediments (blocking issues) that arise during the sprint.
Scrum Masters are part coach, part team member, and part cheerleader.
Scrum Team
The Scrum Team are the individuals that actually build the product.
The team owns the engineering of the product, and the quality that comes with it.
The Scrum Framework for Agile Software Development
Scrum Ceremonies
Planning Sprints
Scrum is a working cadence, or Sprint.
Each Sprint last typically between 2 and 4 weeks.
And every Sprint starts with a planning meeting.
Sprint Backlog
When planning a sprint, your team will typically commit to deliver a set of stories that are pulled from the top of the Sprint Backlog.
Often, each item on the Sprint Backlog is broken down into tasks.
In the beginning of a Sprint, the Product Owner will prioritize the Sprint Backlog items to address.
This queue is based on customer feedback, business value, and other relative factors.
The team then reviews the priorities and commits to the ones that they believe they can accomplish within the Sprint’s timeframe.
Once all members agree the Sprint Backlog is achievable, the Sprint starts.
If you haven’t run Sprints before, we recommend using a fixed two-week duration for each sprint.
While two-weeks is long enough to get something accomplished, it’s not so long that the team isn’t receiving regular feedback.
Daily Scrum Meetings
Daily Scrum, or “stand-up” meetings, are of extreme importance to keep the ball rolling in the right direction, and to keep the team on the same page.
Scrum itself defines different types of meetings required to make your system truly agile.
So let’s touch upon one such very important meeting called the “Daily Scrum.”
A. Duration: Typically 15 – 20 mins.
Daily stand-ups are named “stand-ups” for a reason.
Not surprisingly, every team member will stand for the duration of the meeting.
The point of standing throughout the meeting is to emphasize the efficiency which is supposed to be had in regards to preparation and time.
Each team member should come prepared, and use an equal amount of time as their other team members.
So typically, a daily Scrum meeting should be about 15min.
However, if you have a large team (should be no more than 8 to a team), this could take up to 30min maximum.
B. Each team member answers the following questions in our Daily Scrum Meeting:
- What did you do since the last Scrum meeting (yesterday)?
- Are there any roadblocks which you are facing?
- What will you be working on today?
C. What you’ll need to run your daily Scrum meeting:
- Meeting room or video conference call software.
- Presence of all team members.
- White board, markers, post-it notes, etc.
- Project dashboard
- Someone new each day to orchestrate the meeting.
D. What you’ll achieve with daily Scrum meetings:
- Clear and crisp communication
- Increased team cohesiveness since everyone is aware of each other’s task.
- Transparency, no last-minute shocks.
- Increased accountability.
- Clear sense of your project’s progress.
If you’re already running daily stand-up meetings, awesome!
However, if you’re looking to improve your daily stand-ups, here’s a helpful video…
Concluding Scrum Sprints
At the end of the Sprint, the team performs two practices:
1. Scrum Sprint Review
In a Sprint Review, the team demonstrates what they’ve accomplished to stakeholders.
The review consists of a software demo, which is meant to showcase the user stories that the team completed.
2. Scrum Sprint Retrospective
In the Sprint Retrospective, the team performs a private retrospective to discuss process improvements.
While going through this process, the team takes time to reflect on what went well, and which areas require improvement.
The outcome of the retrospective is a list of actions to be taken for the next Sprint.
This process then repeats itself for each subsequent Sprint.
Preparing for Your Next Scrum Sprint
Once complete, the entire Scrum cycle is repeated for the next Sprint.
The Product Owner will select the next items on the Product Backlog, and the new cycle begins.
While the team is executing the Sprint, the Product Owner should ensure the items at the top of the Sprint Backlog are ready to execute in the following Sprint.
This shorter, iterative cycle provides the team with lots of opportunities to learn and improve.
A traditional project often has a long lifecycle, often of 6 – 12 months.
While a team can learn from a traditional project, the opportunities are far less than a team who executes in 2-week sprints, for example.
This iterative cycle is, in many ways, the essence of Agile.
Finding a Scrum Process That Works for You
So that’s the basic agile software development process when running Scrum Sprints.
Now, going from this basic process to a working one which delivers technology aligned with customer needs requires a more defined practice.
Some of this falls under governance…
Especially if there are multiple teams practicing Scrum.
By governance, we’re referring to:
- The length of the Sprint.
- Formal responsibilities of the Product Owner.
- The tools used to manage the Scrum process.
- And other organizational practices.
On the other hand, the team manages the specifics of:
- What to document in a user story.
- How to fully write user stories in time for commitment.
- The handling of roadblocks after the daily standup.
- How to conduct demos and retrospectives.
That type of self-management exists for a reason…
Because nuances of the project’s requirements, team structure, experience of team members, and maturity around technology often influence how a team elects to run its process.
Challenges with The Scrum Framework
I. Scope Creep
In Scrum – or any methodology for that matter – taking measures to avoid Scope Creep during a Sprint is paramount to success.
This means that you’ll need to know your team’s capacity for work, as well as the amount of work they are committing to when adding issues to a sprint.
Typically, your team should estimate issues before adding them to the sprint, so that you can see the total estimated work for the sprint.
You can match this against your team’s capacity for work by looking at past sprints.
So be sure to use software that will measure and monitor the velocity of work being done for each and every Sprint.
One such software platform is Tara AI, and in the below screenshot you can see a sprint dashboard which can help you keep track of project requirements and team velocity.
However, don’t worry if you have no historical data.
Everybody starts somewhere 🙂
And after running your first 2 or 3 Sprints, you’ll get a good idea of your team’s work capacity and velocity.
II. Failure to Address Technical Debt
Agile software development often requires lots of compromises…
Especially when trying to complete a user story.
And functionality compromises are often debated up-front when writing the user story.
Once a user story is committed to, the development team must make sound technical decisions around its implementation.
Those decisions require implementation compromises…
Even when there are strict technology standards in place.
These compromises create a technical debt, which must be fixed or improved later.
The problem with technical debt, is that it may go relatively unnoticed during the agile software development process.
Technical debt can be:
- Usage-driven when user behavior exposes a technical limitation.
- Driven by performance or scalability.
- Induced by the life-cycle of underlying software components which require upgrade.
So it’s a critical responsibility for developers on an agile software development team to record technical debt.
For small issues, developers can record technical debt in code with “todo” comments.
As a result, the next developer who works on that code can address the previous developer’s comments.
Larger code issues which require refactoring should be itemized on the Sprint Backlog.
Regardless, disciplined agile software development teams will find ways to prioritize technical debt.
You need to address technical debt at several levels:
- For larger application life-cycle issues, it’s often better to schedule one or more releases to perform upgrades.
Additionally, we advise executing upgrades in a release cycle that doesn’t introduce new or changed functionality.
This makes it easier for testing teams to identify issues with upgrades, and it avoids complications when finding root causes may be challenging. - In a release, the Product Owner works with the team to identify the technical debt that affects users the most, has the most impact on developer productivity, or exposes other risks.
The issues identified are then prioritized and should be itemized as user stories in the Sprint Backlog. - In one user story, the team can recommend acceptance criteria, in order for underlying technical debt to be addressed.
Highly disciplined agile software development teams measure technical debt and create indicators when the debt is exceeding acceptable levels.
III. Top-Down Management Will NOT Work
Top-down management is not agile software development compatible, period.
Hence why the Scrum Master is not the project manager.
Although Scrum Masters often take on some of the coordination, communication, and responsibilities of project managers, their approach and core responsibilities are distinctively different.
Project managers often facilitate a top-down project where the leadership has defined a business need, budget, and scope.
And project managers methodologies tend to mimic this top-down approach.
So they look to manage teams toward the goals they’ve identified and the schedules they’ve constructed.
Agile software development, and therefore Scrum, is a bottom-up process.
When agile software development teams collaborate on defining and solving problems with the end-user in mind…
And when there is agreement to follow common practices with a consensus on how to improve the process…
The team can then apply its capabilities and skills to the goals that the business seeks.
This is why Scrum Masters look to serve the team first, and then guide them on the goals and priorities of the Product Owner.
The other major difference is that agile software development is an iterative process.
Consequently, the process enables Product Owners to reprioritize their backlog based on customer feedback and new insights.
This requires different levels of collaboration, practices, and tools to help Product Owners and their teams align on…
- What problems to solve
- And to appropriate solutions when priorities can change Sprint to Sprint.
For example, if you’re used to managing projects with Gantt charts and assigning tasks with beginning and end dates…
You’re going to have to retool and think differently when working with agile software development teams and Scrum.
This is a major shift in thinking around managing projects.
But it works because the ability to use feedback and prioritize or pivot at every sprint yields better results than trying to define everything up front and then execute to this immutable plan.
Looking for the best product management software tools?
Check out our hand-picked list here – Product Management Software: The Ultimate Toolset
Agile Software Development – Ultimate Guide PART 3
So now that you know how everything about the Scrum framework for your agile software development team, it’s time to move onto PART 3 of our Ultimate Guide to Agile Methodology for Software Development.
If you have Scrum or Sprint tips to share, please comment below!
We want to make this guide as useful as possible, so please don’t hesitate to tell us your stories 🙂