My expectations from Agile Scrum

Beata Zoldi
Sep 7, 2018 · 7 min read
Image with a post it that says: Start Doing

As a young developer, I had the misfortune or luck to work both on established agile teams and teams that are shifting to agile. There were days when I hated staying hours in meeting rooms refining PBI’s and there was a time when I missed those refinement meetings or a well written PBI per se.

Agile is about adapting. Agile Scrum is only a means to an end. It gives you a starting point but not a destination and it’s up to you what the process will become. All the organized and unorganized chaos I experienced in three different teams made me wonder what are my expectations from Agile Scrum. I read the official Scrum Guide and I know the rules… but most of all I hated the never-ending meetings where I was present only to get the headcount.

I came up with 3 ideas! Three ideas that I would put on a retrospective board before the first ever sprint.


1. Make scrum events count

Keep scrum events (meetings) that engage participants not make them take mental trips to fairyland.

You, as a team, chose Agile Scrum so you will start with the basics… you put on your calendar all the official Scrum events. Do not drop them before you’ve tried them out, instead keep in mind that you have control over the length and the course of those events. Use your time well to engage all the attendants and discuss topics in a well organized and clear manner. Enhance from the beginning the main purpose of the meeting so there is a common goal to achieve. Make a clear agenda of the topics that should be discussed. Starting a discussion in a team without a common ground will let place to personal preferences, and it will fail to engage all participants and generally will end with no conclusion.

If you think that you need more time because the team is not adjusted with the process, book only 10 minutes more. Take that extra time at the beginning of the event to explain to the team what is the purpose of the meeting and what should the team expect from it. During the remaining time keep to the agenda and make sure that all the members can communicate their concerns, problems or proposed solutions clearly in a safe and constructive environment.

It will be hard in the beginning but if you succeed you will have fewer meetings and more results. It’s up to you how you will manage to keep people on track. Maybe steal a sheet from the agile book and time-box the topics or pass a ball between team members. Until it works out for your team and you get the expected results, keep up the good work!

2. Less is more

Time is money, so it is in the scrum team’s best interest to manage it well!

Do you remember what went wrong in the first week of the sprint? After 4 hours spent in the meeting room is it still clear what the main topics are? The more time we have, the bigger the chances we will find time to procrastinate, take a detour or simply delay some complex problems. Simply put, we think that we have time to do the unit tests, refactoring or documentation! And here comes the last week of the sprint, or the last minutes of a meeting and the rush begins. The results are simple: stories are not tested or fully implemented, we write the unit and integration tests “next sprint” and we will have another meeting of an hour to discuss the topics we could not include in the current meeting.

Another important aspect to take into account is that, the longer the time frames we choose the more preparation is required. Complexity will rise, estimations become vague, meetings become longer and the team will have a hard time focusing. I think is better to start with shorter periods and expand them only if it’s really necessary. And trust me I know it takes time to deliver a complex feature, discussions about architecture are never ending stories and we need to run exploratory and regression tests too. There is no way to do it under 30 days!?

Keep in mind that you are responsible to deliver an MVP during a sprint. Your main purpose as a team is to deliver added value not to solve many backlog items. You are completely in charge and everything is up for negotiation!
Spending 30 minutes discussing only one of the many topics planned during a two-hour meeting will not lead to the best results. Try not to discuss too many details over unwritten code or abstract ideas. Have enough to start your task and go into the details only after trial and error.

Promising many features but delivering only some of them is another indication that you lacked the fundamental understanding of the work included in the sprint. Maybe you even have a motive like: waiting for others to implement their part, or merging hell that took you two days to resolve because two complex PBI’s impacted the same code base or simply you needed to detangle a spaghetti code before you can start adding your implementation. All these idle times could have been prevented with some better planning and a better understanding of the tasks. If you learn from one or two failed sprints and you improve it’s ok, you are on the right path. But if you tend to book more and more meetings to discuss remaining problems or re-estimate open tasks you might end up with yet another failed sprint. In cases like this, you should seriously need to reconsider your judgments over the process. And the root cause was only bad time management. The team had a false impression that more time equals more backlog items, and failed to predict and analyze possible problems. When you have less time you will assume less, but you will do it better cause you can focus better.

And never ever forget that time management should be mastered by every team member, so maybe next Monday when you are in the front of the screen thinking about writing “Hello World” using only the word chicken ( been there, done that… :)), think twice and instead do that difficult task. Chicken can wait till the code freeze!

3. Sharing is evolving

There is no wrong question but… There is more value in a well-defined question than in an ambiguous one!

If your team wants to benefit from Agile then first of all the required resources (architectural document, design mocks, test cases, epics, etc) should be accessible to everyone and visible all the time. The information inside those resources are tools that should be used in everyday activities. You don’t ask where your IDE is located so you shouldn’t ask where the design mocks are.

Transition to Agile is hard but while teams usually start learning the new tools and have their calendars full with the new events they often forget that the power of Agile lies in the value of the people that form the team. The composition of a scrum team can be diverse. In some places, each member of the team does design, implementation, and testing. And there are other places where all those roles are separated into three different team members. Maybe there are places where the team member that does design serves more than one team.

Keep always in mind that you should encourage each team member to work on their T shaped skill set. Without this, there is no valuable Agile process. Don’t get me wrong, I am not saying that each team member should master all the topics that are implied in the creation of the product, but all team members should know at least the basics.

Learn enough that you can continue working even if a specific expertise is missing from the team. And share enough about your area of expertise that others don’t bother you with ambiguous questions.
The product is the reflection of the team. A team where each member stays and focuses on their area of expertise will create well-defined parts of the product with the hope that it will work well as a whole. You need to deliver a product that is usable for a user, so aim for a team that has the goal to do that.

The architectural documents are not only for developers, and a test case is not meant to be run only by a tester. All building blocks should be shared and understood by all team members. Responsibility is shared inside an agile team so you as a team member should know every aspect of your product.

For knowledge sharing, there is no responsible person! You as a team need to take initiative.

Are you not capable to test well your code?
Ask for help from someone that does a lot of testing!

You have no time to answer the questions of the others because you already have too much to do?
Ask for more time so you can help others with your expertise.

It takes time to form a good agile team, but you need to take actions from the very beginning.


Agile Scrum is a framework. It’s a way to help you build your own process. So why would you treat it any other than a normal framework like Angular for example? Learn the basics, read the articles but observe, think and adapt. Everything is up for negotiation so argue and change, and most importantly have some patience.

Give or take Agile and Agile Scrum has good and bad parts. All members of the team will have their personal frustrations and preferences. I wrote about mine but I would be more than happy to hear about your experience with Agile Scrum or any other Agile method or development process. You know… sharing is evolving! And I hope that I could learn something from your experience.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade