This is a guest post by Dee Ann Pizzica.
Almost every organization where I’ve worked in the past 15 years would describe themselves as an agile shop. Yet somehow every experience I’ve had with teams throughout my career looked slightly different, even though we all used the same words. Some teams were highly successful with Scrum or kanban, but others really struggled.
Some teams have a negative view of agile development due to unpleasant past experiences. What happens when you find yourself leading a team that doesn’t like agile? What can you do when you can’t use Scrum rituals but you still need to plan? What techniques can you use to break up the work into meaningful milestones that help the team deliver work consistently?
You don’t want to go back to waterfall, but you can’t really be agile.
Here are a few suggestions for a “Scrum Light” process for teams that have an aversion to agile rituals.
The problems teams have with agile
First, it’s important to understand why some teams can be so turned off to agile.
No two team members are the same
Scrum was never a perfect fit for me because for years I was always a tester. Right out of the gate I was never going to be one of those interchangeable parts on a team. While I might work a little on every story in a sprint, I was never going to be able to pick up the same tasks that the developers on my team were going to take. The idea of anyone on the team being able to work on any user story was patently absurd to me.
In the beginning, I thought it was just testers that felt that way, but over the years I’ve watched that sentiment play out among developers too. Each engineer brings different interests, expertise, domain knowledge, and experience to the team. Even when there is a sense that most team members are capable of completing any of the tasks in a given sprint, not everyone is going to want to.
Ultimately, team members want to be recognized and appreciated for their individual skills. They want to pick up tasks that are interesting to them, not just grab the next story on the pile because it’s in the order that the product owner specified.
Commitment is a dirty word
What about commitment? Often, teams are told they are empowered to push back, but in reality, that’s not true.
Not all leaders want agile processes in order to empower teams. Some adopt agile because they believe it will help to solve existing organizational problems and to ship consistently. Some leaders push for agile because they believe the team’s output will be better, faster, and more amazing than ever before.
How long can you work on a team like that can’t push back before you feel burnt out? How long before you blame “agile” for everything?
Meeting fatigue
Scrum is a meeting-heavy process. You’re committing to meeting and discussing projects upfront and to grooming the backlog together in order to increase buy-in and understanding of the work. The tradeoff is that the meetings make everything clearer so that when the work happens, the team can stay focused.
However, often these meetings drag, or there are discussions that not everyone is an active part of. Team members may feel that their time isn’t well utilized and they aren’t getting value from just sitting around. Despite your attempts to keep everyone engaged, people inevitably tune out.
Now what?
All right, so you understand some reasons behind why teams can dislike agile. Now you have to find what’s most important about agile ways of working for your team and throw out the rest of the rules.
For die-hard agile fans, this can be hard, especially when you respect the rules and see value in them. For teams that are never going to come around to your ideas, you need to be creative in order to succeed. You must compromise.
Here are the agile components I refuse to let go of. Maybe they will work for your team as well.
Handle Handoffs
I start with handoffs. No single person on the team is likely to complete every step of a given project. If that were the case you, wouldn’t be too worried about Scrum, would you? The most critical problems in any software project are where different teams or people meet.
On a Scrum team, handoffs are discussed in daily standups. But they’re also managed by tracking status on user stories. Do you really need a daily meeting if the team is using a tracking tool and they’re going to talk on Slack all day anyway? Combat meeting fatigue and challenge your need for a daily standup.
When the team knows the critical information that needs to be communicated, they’re often willing to share in a different forum. Try “Slack-ups,” where everyone posts their statuses in a team channel. You can use a bot for this, or if that feels too structured, someone on the team can kick it off every day.
Slack Bot Model
There are a number of different bot integrations for Slack that will manage your standups. Set a time, define your questions, and schedule it.
You can stick with the standard questions:
- What did you accomplish yesterday?
- What are your goals for today?
- Do you have any blockers?
I like to make sure the team is focusing on anything they need from anyone else. Team members should call out if they need code reviews, testing, questions answered from the product team or help from design, so I usually include something like:
- How can your team help you succeed today?
Ban the Bots
If you’re not using a bot, you can be a little more flexible. You’ll still want the team to answer some standard questions so the basics are covered, but you can also include other ideas to spice it up a bit.
For example, whoever is kicking off your standup for the day can lead with a silly icebreaker question that everyone has to answer. You can also try to issue a themed challenge, like starting your update with the funniest kitten gif. Then each person on the team reports in and tags another person to go next.
If your team is looking for a little facetime, try Slack-ups a few days a week and quick meetings the other days. I like an in-person meeting on Monday so that the team can say hello after the weekend and preview the work for the upcoming week. You have to experiment a little to find what works for your team — maybe a Friday demo and happy hour is more your speed.
Define Scopes
Planning and grooming meetings can be extremely time-consuming, and it can be difficult to ensure the team is prepared beforehand and engaged throughout. Rather than having long meetings to write and review user stories, you can try to do some of the prep work asynchronously and then get the team together for a shorter kickoff meeting when you’re ready to start.
Every project starts with an idea, and it’s important to document all the key details. My team uses a variation on the process outlined by the folks at Basecamp, who published a book called Shape Up.
We start with an idea and a person or two writing the first draft of the project scope. Our template contains these basics:
- Problem: What are we trying to solve?
- Appetite: How much time are we willing to spend?
- Solution: What do we need to do?
- Rabbit holes: Where do we think we’ll run into problems?
- No-go’s: Anything we’re specifically excluding from the scope?
Once the initial plan is written up and we feel reasonably confident that the project is worth investing in, then we start to socialize it. The product manager will send it off to a tech lead or two to get some feedback and make revisions accordingly. We’re especially looking for more rabbit holes and no-go’s at this point. As we become more sure of the project, we involve more team members. This can take place in short meetings, but it is vital that the team review the document and come prepared with questions.
We specifically try to leave the solution more flexible so that the team has room to explore how they want to solve the problem. This is rewarding and empowering for them. Also, by calling out risks up front, the team has a higher chance of success as they begin creating solutions.
Once the project is scoped, the team does need to break it up in order to have manageable work items. For our process, we like the project manager to create some user stories that outline the high-level goals based on the final version of the document. These user stories give us something to track as we work through the project. They keep the team aligned with the problem we’re trying to solve and provide information that the test team can use to verify essential functionality. Each story is assigned a label for the piece of scope it fits into. From the stories, teams can create tasks for implementation and testing however they see fit.
Prioritize the scopes and allow the team to manage which ones are most important. Instead of a sprint planning meeting where a product owner decides what user stories need to be in each sprint, try letting the team decide which stories they want to work on first.
It helps to have a sprint board for visibly tracking the work in progress, so use a tool for that. But for a team that feels like they have been burned by Scrum, forcing them to commit to completing a certain set of stories by the end of the sprint may cause a lot of pushback. Instead, encourage the team to reflect on the timeline that’s outlined for the project, and work backward to figure out how much work needs to happen each week in order to get everything done. Allow the team the flexibility to move stories around mid-sprint based on what they’ve learned and what they want to work on.
Mind Priorities
So long as the major scopes are grouped and defined, we have a way of measuring how close we are to finishing the project at any given moment. Scope creep is one of the most common problems in any project, so monitoring progress on the scopes is important.
Inevitably, the team will discover unexpected scenarios as they dig into their work, and there are always opportunities to refactor and leave the code better than you found it. It’s great to give the team some flexibility to explore these ideas as they come up, but depending on progress you may not be able to indulge every whim, so be prepared. Every new idea and discovery needs to be weighed against the known scopes and the original problems documented before the project began.
The same problem comes up once you let your testers loose on any new features. Your testers may discover regression issues, or they may log feature requests for improvements. Sometimes they’ll even find problems that the team hadn’t anticipated. Each of these contributions also need to be weighed against the scopes and team progress.
Remind the team that prioritization is key. Sometimes it’s tempting to try to fix everything, but we need to pick and choose our battles if we want to finish on time. When a new idea is important but too time-consuming to pursue during the project, encourage that team member to document the idea for future consideration so that what they have learned isn’t lost.
In Scrum, you’d remind the team that you’re looking for a minimum viable product, but when you can’t use agile terms, just remind your team that there is a set of scopes that everyone agreed was important before you began.
Find What Works for Your Team
You sometimes may feel like you’re reinventing the wheel. You’ll get frustrated. You’ll get tired. Some projects are going to run over schedule, and others may simply fail. This is where retrospectives can help. You can call it a retro, or you can call it “iterating on your process,” if that sounds less intimidating.
Finally, make sure you take the time to praise the team for work well done, and seek their feedback for opportunities to improve. Try giving the team more responsibility and freedom, but still offer some basic structure. You may not be agile, but you are flexible, and that might be exactly what you need to get the job done.
Dee Ann is a passionate and curious software tester. She has over 15 years of experience in support of small and enterprise-scale custom mobile and web applications with highly complex business logic for clients across a wide variety of industries. Dee Ann is currently working as the Director of Engineering at BRD where she collaborates with a talented team on a cryptocurrency wallet app for iOS & Android.
