You've gotten agile training and the team is motivated, but are you really set up for success? As teams make the transition to an agile methodology, they often face challenges and obstacles that keep them from realizing the many benefits that agile development promises.
Let's take a look at how teams that are new to agile can best prepare for a successful first agile sprint, along with common mistakes and how to avoid them.
Before the first sprint
There's a fair amount of work that must be done in preparation for that first sprint. First, there are the logistics of determining which agile methodology, process, and tools the team will be using. There will be work to procure any needed hardware, software, and set up environments, and to make sure teams are properly staffed. Finally, there will be some work to understand the technical framework and prioritized requirements.
If the team is using scrum, arguably today's most popular agile methodology, this early work might be referred to as "sprint zero." This stage of the project needs to be completed carefully.
Mike Cohn, well-known scrum leader and founder of Mountain Goat Software, says that one of the problems with a "sprint zero" is that it most likely won't result in potentially shippable code if the team is still in the process of assembling. He says, "I find that many of these things that can be used to argue for the need for a sprint zero are really best thought of as things that happen in what I call the project before the project."
However, Cohn cautions when executing the project before the project:
- "Keep any 'project before the project' as lightweight as possible. Most development projects do not need a project before they begin."
- "Remain true to the principles of scrum. A team participating in a project before the project will not be able to have anything potentially shippable. That's fine. But understand why having something potentially shippable is a central tenet of scrum and apply that in an honest way to the project before the project."
For larger software development teams, the basic principles of scrum may need to be scaled up in some fashion. Over the past decade, agile thought leader Scott Ambler developed an augmented set of agile methods in Disciplined Agile Delivery (DAD). He warns against the naivete of a simple sprint zero. He advises those starting a new agile project to begin by using the method outlined in the Inception phase of the DAD methodology. This would include identifying the initial technical strategy.
DAD's Inception phase also includes defining the initial scope of the project. In scrum, this is referred to as populating the product backlog. Whether you're using DAD, scrum, or a different agile methodology, having a prioritized list of your high-level requirements or your product backlog is a key input going into the first agile sprint.
The first sprint
Now that the prep work?whether in the form of a DAD Inception phase, a "sprint zero," or a "project before the project"?has been completed, it's time for that first sprint.
While there are plenty of books and experts who evangelize their favorite best practices for their preferred methodology, it's important to remember that any agile method expects us to inspect and adapt over time. Your first agile sprint is a baseline and getting everything "right" isn't as important as getting the team to understand the general spirit of agile. The iterations are short so the team should be able to quickly gather feedback and continue to adapt and improve over time.
Barnaby Golden, agile coach and scrum master, warns against doing too much in the first sprint, yet he still encourages delivering a small amount of business value. He advises against trying to get too much accomplished this early and recommends these steps:
1. Start backlog refinement early to prepare the team for sprint two.
2. Establish your test approach (test frameworks, process, etc.).
3. Ensure that all environments are set up.
4. Put any required automation in place (continuous integration, automated releases/deploys, etc.)
"It's a good idea to try and get some business value out during the first sprint, even if it is just a 'hello world' type thing. The reason for this is we want to start engaging the stakeholders and the best way to do that is to deliver working functionality."
Although there's no single "right" way of doing things in agile, the scrum method recommends the sprint planning meeting on the first day of the sprint, the daily standup meeting each subsequent day of the sprint, the sprint review meeting, demo, and the team retrospective at the end of the sprint.
Sprint planning
During the first sprint planning meeting, you'll pick the user stories for your initial sprint. Golden's recommended approach is consistent with what most scrum coaches advise. Focus mainly on stories that will get your infrastructure and processes in place, but plan to have working software for the demo at the end of the sprint. Keep the coding simple for this first sprint. Coordinating the use of tools and processes and establishing high-quality practices from the start is important?this will set the stage for good coding practices going forward.
Estimation using story points will be difficult during that first sprint because the team won't have a history of their velocity or a good understanding of what they can typically accomplish in a sprint. During the sprint planning meeting, the team members should ask enough questions to be very clear about what the "definition of done" is for each story and to be specific about the tasks that need to be completed. Though they may be uncomfortable with story pointing or new processes, they should move forward, realizing that as time goes on they will develop greater levels of understanding as they adapt and improve.
Throughout the sprint, the team will participate in the daily standup meeting and have a chance to note any obstacles they're encountering that are preventing them from completing their tasks. The scrum master, with the help of other team members, will work together to remove those obstacles so the team can reach the agreed-upon definition of done for each story.
On the final day of the sprint, the team will host a sprint review and demo with their stakeholders. With expectations set at the beginning of the sprint, the team will demo the completion of the agreed-upon stories, recognizing that having all the pieces in place to produce working software is a major accomplishment for the first sprint, one that is worth celebrating.
Inspect and adapt
Inspecting and adapting are important everyday tasks as the team continues to coalesce and learn from challenges. The team retrospective, held after the first sprint, will give the team a more formal opportunity to talk about the challenges faced and work together to determine how they will improve in the upcoming sprint.
It's common for any team new to agile methods to experience some amount of pain as they're learning. A common mistake that many new agile teams make is to run their iterations like "mini-waterfalls," doing all the development up front and then passing code to testers at the end of the sprint.
Matt Heusser of Excelon Development shares this experience of a bad first sprint:
I worked with one team that had some scrum trainers come in before me (and later rotated out). They were good people, with good ideas, and they were sincere...and they pushed the idea of a "sprint commitment." Which means, no matter what, get the stories done. This resulted in testers working on Saturday and Sunday, only to find bugs. So the people felt pain AND management still felt like the team wasn't committed. Everyone lost!
Though you do want team commitment, it appears that in this case the team was working in a traditional manner, expecting the testers to test everything at the end of the sprint (into the weekend), leaving no time to fix the issues that were found. Instead, developers and testers should take a "whole team" approach to quality and work together throughout the sprint to ensure that each story is bug free.
Another common challenge for new teams is confusion and uncertainty about whether or not they're correctly following the methodology or doing things the right way. It would be best to have an experienced scrum master or agile coach to help the team through challenges they're facing. However, agile leaders act more as facilitators, coaching the team to come up with ideas about how they might best resolve their specific challenges as a team. Special attention should be given at the team retrospective to hear from every team member and to set specific actions that will be taken to make improvements for upcoming sprints.
Getting used to it
Though an initial sprint can feel awkward as team members adjust to new processes, as everyone gets accustomed to the agile methodology, they will improve over time. The team will face challenges, and that's to be expected. The autonomy that comes from making decisions and continually improving motivates team members to perform at their best. Most people find that once they make the move to agile, they don't ever want to go back.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
