Scrum / Agile is not broken but we need to stop pretending
Scrum might be a foot-gun so stop trying to make it fit. There, I’ve said it.
Don’t get me wrong, I love working on agile projects. I’ve done it in the past, I’m doing it for some of my projects and I will do it in the future. But right now, I am not working agile. Grab your favourite beverage (appropriate for your current time and location), sit back and listen to a story of horrors, pain and closure.
We will look at the Idea of Scrum, possible problems, ways to fix them and times when you should not force yourself into the corsage of agile workflows.
The Idea of Scrum
The idea of Scrum and working agile in software development has been around for a while and currently, it seems to be the craze in almost every company you encounter. There’s scrum masters, daily meetings, reviews and retrospectives and people left and right are either cheering or crying about it.
Project managers love the idea of Scrum. All tasks broken down to stories you can put a t-shirt size on, the team has a velocity of 42 and you know exactly what you can achieve in the next 2 weeks.
The team loves the idea of Scrum. They understand what everyone on the team is doing. You get to know each other, sit together to talk and play planning poker for new tasks and never before was there so much confidence in everyone to get things done.
The customers love the idea of Scrum. They get small bite-sized chunks of his project delivered and can follow the progress while making changes where needed. They can get their money sack stories prioritised and everything is fine… but is it?
How come that everyone loves the idea of Scrum but in the end, in so many cases, so many people are unhappy with the process, the amount of micromanagement and meetings?
Possible Problems
There are several reasons, why your agile workflow is not working. Some of those can be solved, others not. It takes some experience and patience to tell them apart and turn the idea of Scrum into a reality.
You and your team were eager to start working agile. You sit together, plan your tasks, work out realistic estimates and plan your first sprints. A few weeks go by and your team sits together in their second retrospective, talking — again — about a failed sprint where you did not meet your target. Hopefully, everyone works together to find solutions and changes are agreed on. Your start the next sprint and again, you fail. Obviously, this isn’t working as intended.
When starting to work agile as a team, it is very common to not meat your own goals. Maybe you finished the first sprint early and took in too many tasks/points for the next sprint. Maybe your team still needs more experience in making estimates, breaking down tasks and spotting issues before they occur.
Finding your own “velocity” in an agile team takes some time. I usually say, wait a few months before you start making big changes. Do talk about issues openly, even with the customer present, when they are part of the agile workflow. Communicate transparently and try to improve your estimates, plannings and sprints in very small iterations. If you have not been working agile for years, chances are, you and your team still need to grow into it and if the team size changes, you might even have to start over again.
You have your daily meeting, a backlog refinement, a sprint planning, sprint review, sprint retrospective, feature kickoffs, lunch break and maybe, if you stay late, you even manage to get some programming done.
This is something I can talk about at length as I recently started working part-time, taking care of my daughter for the rest of the week. Working only 24 hours a week, I can finally fully understand what many of my female colleagues were talking about in the past, telling people to send more emails and do fewer meetings.
Working in an agile team comes with many meetings but… they are there for a reason and you can make them work. There is one key point here I need to stress. Discipline!
Everyone in the team needs to adhere to meeting discipline! If you are a few minutes early to a daily meeting, it’s ok to goof around for a bit until everyone is there and the meeting starts but a daily meeting should be as short as possible. Never start late, don’t stand around waiting for the late-comers. It is often called “Stand-Up” for a reason, don’t sit comfortably and talk lengthly. Keep it short and precise. “I did this task yesterday and will start this today. Bob, I need that chart by 12 for our customer call and I still need access to database X, this is a roadblock for me.” And cut to the next person.
Ideally, you are all done after at tops 15 minutes and can start into another productive day. The same goes for other meetings. Keep them as short as possible, set a fixed time and when you are not done when the alarm goes off, finish next week. If the team can’t do it on their own, hopefully, your Scrum Master can make up for that with moderation and people skills.
With the regular sprint meetings and a 3-week iteration, you will usually spend around 8 hours total in regular sprint meetings. Make sure these don’t drag on and waste everyone’s time.
Your client is not working as agile as your company does or is at a remote location and can not join you for one reason or another, which means that they can not fill the role of the Project Owner. Your Project Manager now puts on the hat of the “Proxy-PO” and you move on. As your company is small and does not have a person to spare, you decide on one team member to take over the role of the Scrum Master in meetings and you hurriedly send them to a few seminars on the topic.
The hard truth here is, there is no real clean-cut solution. Unless your team has loads of experience working agile and is confident about their workflows and everything, you need these roles! You really do.
The Project Owner is the stakeholder. The PO tells you what he wants or needs and in which order and priority. The PO decides which stories need to be added to a sprint and makes the tough call to drop another story or two to adjust to the team’s velocity. The moment that your Project Manager is also the Project Owner, interest start to mix and this can lead to issues with setting the right priorities to make the customer happy and we all want a happy customer, don’t we?
The Scrum Master is your bulwark and your problem solver. The scrum master needs to help everyone in the team to shine and get their work done. This can be a full-time job in many cases. An SM needs to make sure the team can do their work, has all the information and access to all systems and resources. Spotting possible roadblocks, dead ends, bottlenecks and other issues that might lead a sprint to fail early are some of the key tasks of a capable scrum master.
They defend the team against corporate and project lead interests that might clash with their tasks on the project. Some times the SM even protects the team from themselves and serves as a lightning rod for problems that arise during a retrospective meeting, gathering all available intel and help the team to identify solutions and actionable ideas to move forward.
You need those two, believe me. Be nice to your Scrum Master, he is your best friend at work.
You and your company are trying their best to be as agile and productive as possible but the client is not agile and due to corporate or “political” reasons does not agree to work agile and pay agile.
This is one of the moments where you need to face a sad truth, you will not be able to work fully agile. It just won’t work.
Don’t force yourself
There are situations where working agile will just not work. Maybe these reasons are outside of your circle of control. Trying to force the mantle of Scrum on a team or a company can lead to disgruntled and unhappy employees, bad project management and even completely destroy a team’s productivity and happiness.
But there is still hope. There is still a way that is working quite well for me right now, gets things done, helps us meet deadlines and keep everyone happy. I like to call it “Agile’ish”.
Take the best from working agile and apply it where possible.
Keep up regular short meetings to get everyone on track of current tasks. Plan tasks as a team. Get ideas and feedback from everyone and get everyone on the team involved. This does not only help people stay in touch and feel like they are part of the whole project, it creates a feeling of ownership.
This is our project, our code and our success.
Work iteratively and keep the main project running. Use the Git Workflow and keep features small. Write Proof of Concept features and build them up. Never let a branch get older than 2 weeks top before merging a working version back into the main trunk. The longer a feature exists in isolation, the more likely it is that you will run into major issues when you try to merge.
This is our project running on staging. Isn’t that cool?!
Get feedback from your peers about your work. Don’t stop at code reviews (also never stop code reviews!!!) but ask for an honest and fair feedback. Create an environment of trust and honesty, where people can talk to their colleagues freely and with no fear or suspicion. Get together regularly in small groups and gather feedback on processes, refine them and commit to them.
This is the way we build our project. We all agreed on this.
Analyse and break down tasks into bite-sized chunks that you can understand and plan. Write down user stories that explain the task from the perspective of a real person using the software and then create tasks needed to perform to reach that goal. Look back on similar tasks and try to get a good feeling on the complexity and possible issues to put a number on those tasks.
This is what we need to do to finish our project. We have a plan.
Wrapping up
Maybe your company might not get the official “SCRUM Certified” label, maybe your customer doesn’t want to work agile and maybe there are some things you just can’t change but that is no reason not to try to be a better you tomorrow than you were yesterday.
Take from the Agile Idea what works for you and add it to your repertoire. See what works and what doesn’t and keep iterating. Maybe don’t tell your friends and business partners that your company is working agile, maybe stand proud and say:
WE ARE AGILE’ ISH AND WE GET THINGS DONE!
Happy Coding, everyone!
Some words about me:
If you want to see more of my work and progress, feel free to follow me and check out my other articles. If you clap feverishly for the articles you like most, it will be easier for me to decide which directions to pursue in following articles so use your ability to cast a vote for future content.
I’m also currently working on other series covering complex React Native Setups using Typescript and scalable apps with Redux, where I’ll go into details about how and why I do stuff the way I do as well as some articles on my experience in building games for web and mobile with React.
Here are some of my recent topics:
- React Quick Start with Typescript, Redux and Router
- Linting/Prettier with Typescript
- Redux + Toolkit with Typescript
- Spread & Rest Syntax in Javascript
- clean and simple Redux, explained
- Game Theory behind Incremental Games
- Custom and flexible UI Frames in React Native
And if you feel really supportive right now, you can always support me on patreon, thus allowing me to continue to write tutorials and offer support in the comments section.
