Putting out the fire from the angry scrum team
Complaints from Product Owners
“My team is not efficient and the velocity is lower than the other teams (squads).” “ I have no idea what the developers are doing and why things are going so slow.” “ I’m going to meet with them more frequently to check their progress each day.” “Things keep getting carried over to the next sprint and almost nothing is done in time.”
Complaints from Developers
“There are just way too much work and the product owner is not reasonable.” “I’m tired of hearing things like ‘it’s just a button why does it take so long’.” “There are so many status update meetings and it’s eating up all my development times.” “Everything’s high priority! So many adhod tasks creep in every sprint and they wonder why we’re behind.”
The above questions and complaints are probably something that you have either heard of or have said it yourself. Espeically in view of the recent pandemic, when working from home has become the increasing norm, doubting team members, pointing fingers when things go wrong, being unnecessarily interrogated by POs can be more rampant than ever before. The main underlying issue here is the lack of trust within the team. After some retrospective sessions I have gathered the below advice for both developers and product owners.
A word for the developer
Be transparent as to what you’re doing
Imagine that you’re installing a software on your computer. You know it’s a big software and it’ll take some time to complete the installation. As with most software installation there’s a progress bar that tells you where it’s at with the installation process. Perhaps it’s downloading the packages, perhaps it’s doing the installation, or perhaps it’s updating the system registry. But imagine that during the installation processs all you see on the screen is this…
No percentage, no logs, no animation, and no error messages. It just says installing and that’s all you see. You wait and wait and wait and nothing happens. After a while you may decide to terminate the installation altogether and try something else.
As a developer if you’re not transparent as to what you’re doing then no one knows what you’re doing. If you are forever on the same task and not updating what you’re doing, then your scrum team may have the similar feeling of looking at a nonmoving installation progress bar and decides to terminate the project or ask other members to jump in. Trust is not something that comes naturally, it needs to be built up.
Keep the board moving and make your progress public
Don’t ever let your jira board be stale. Your jira board should properly represent your work on hand. As a fellow developer I understand that it is a lot of hassle to create subtasks, move the tasks from to-do to in progress, in progress to peer review, etc. But you don’t want to be that installation window above especially if the trust relationship has yet been built up between you and your colleagues. To ensure that the board is moving, break your tasks down into reasonable sizes. This will not only help others to know what you have on hand but can also help remind you where you left off from the weekend.
Be transparent as to what you’re assigned
Every now and then there will be adhoc tasks that will come up and take higher priority than what you already have on hand. It might be an urgent report that management needs to see. It might be a production bug that needs to be addressed right away. Whatever it might be if it comes up and is taking your time, you should mark it down on your board (ex: jira).
Do not ever think it’s too much of a hassle. If you don’t write it down, no one knows, and after a while you yourself can’t even explain why you were so busy. Writing things down gives everyone a transparent view including yourself. Sometimes I have trouble remembering what I worked on 2 days ago but when I keep my jira board updated, even if I get behind on schedule, I’d be able to explain the reasons why.
Establish trust within the team
If you have trust established then there’s no need for others to micromanage you. But it takes time for trust to be built up. Being transparent, according to my past experience, can knock down quite a few walls between you and the team.
Of course being transparent alone is not effective, you also need to take ownership of the project itself rather than just work for the project. Be proactive to ask questions and explore possibilities together. If it ever happens that you finished the work early within the sprint, go a step further and take up a bit more, contribute some of your ideas to the team.
A word for the product owner
Until AI technology is mature enough and machines are doing the development work instead of actual human developers with flesh and blood, it’s best for product owners to adjust to the expectations from the management team and also from the developers.
Everything takes time and effort
Commonly speaking, most product owners do not have a technical background and therefore they are not the experts in the development work itself. Every little small task, even if it’s just a simple fix takes time and effort. It could be as simple as enlarging the font size of the header in that page, it’ll need to go through a pull request, peer review, CI/CD pipeline, promotion to staging environment and then finally to production environment where the font is finally enlarged. And these tiny fixes add up and pile up and eventually they themselves become a story.
Another meeting will only be counter productive
Status update meetings can be very helpful only when used with caution. It might be better to train up the developers to write better description for the task that they’re working on in their ticket than to host another meeting. Hosting another meeting to criticise why things are not going as scheduled can be the last thing that’d bring any value to the table.
Manage the expectation for your superior and team
I understand that the PO is often the one in the frontline taking most of the bullets. Whenever something is delayed the PO is the first one to take the hit. It takes courage, boldness, and smooth bargaining skills for the PO to manage the expectations from his own superior. The same goes for the development team. You can’t have everything as a high priority. A good PO is a PO who’s willing to take out an existing task when there’s another one that needs to be added with higher priority.
If you’re given a bicycle and are expected to get from Hong Kong to Beijing in a day, you’ll end up being very disappointed. At some point we all need to realise that you can only work with what you have on hand. If you’re given a car then set the expectation reasonable for a car; if you’re given a rocket then set the expectation based on that. It usually takes 2–3 sprints for the velocity of the team to be apparent, so let’s be reasonable.
Reward the team and let them have small breaks inbetween goals
After a big release, let the team have a small break. For some it could mean decrease in velocity, for others it could mean picking up the light weight stories from the backlog and make the sprint an easier one. You never know how much time the developer spent outside of work to get the production release out, have a time to celebrate with the team!
Trust the team that you’re working with
I’ve had a few PO/Manager from previous experiences where they always think that the developers have too much free time and are lazy. If the developer is already being transparent as to the work they’re doing, the PO also needs to cooperate by cutting the team some slack. Every now and then you might catch your developers taking a small break. It might be a quick coffee run, they might just need some sugar to stimulate their thoughts, or they just need a 15 minutes nap because they’ve been overtiming too much. If it’s reasonable let the team have some freedom.
If the developers didn’t respond immediately to your message, give it a 5 minute wait, especially if they are working from home. Working from home is not the easiest thing in most cases. Their kids might have made an incident, something could be burnt from the kitchen. If it’s not that urgent, it’s ok to wait a bit. No one likes to micromanage and no one enjoys being micromanaged, unless you’re the rare exception.
Last words
I hope this has been helpful and applicable in your case. If you have any other feedback that is revelant, constructive, and helpful to others, please do leave a comment below.
