Each day presents something new to learn.

Most Teams that regularly run a Sprint Retrospective use the dreaded quadrant, What worked well, What Didn’t work Well, Ideas and Actions (and variants of this quadrants). I am sure your team has used this format many times. I coach Scrum Masters and their team to always prepare for Sprint Retrospective, and part of planning is observing the team all through the Sprint and experiment with different formats for running the Sprint Retrospective.

I was invited to a meeting titled “Let’s hang and code”; it was for 2hrs and out of curiosity, I attended.

This meeting was an idea by the Tech Lead of a startup that I am currently working with. This is a startup where the entire team works remotely and the purpose, I learnt was to foster relationships between the team members and support people who might need help with the task they have picked up for the current sprint.

1. You assign tasks to subordinates and chase up for updates as soon as you feel they should have been done.
2. Regardless of what your subordinates are currently doing, you believe they should be working on something else.
3. You have just assigned task to a subordinate and immediately you follow up with instructions on how they should be doing it.
4. You are so bothered about how they spend their time; and you just need to ensure that they have enough work for 40 hours a week, that’s what their contracts says anyways.
5. You feel that your subordinate should be able to multitask as that’s inherent in humans.
6. Your subordinate shared a better idea but you don’t trust that they are smart enough; so you insist it must be done your way.
7. You subordinates are part of a product team but you want to keep them in a siloed functional team where they report to you.
8. You really need a daily status report - What they are current working on and what they did the previous day.
9. You believe that you need to help your subordinate prioritise their work as they must be struggling.
10. You need to make a decision, even when your subordinate could have made these decisions; at the end of the day you are the BOSS.

Does any of these resonates with you? Managers have a crucial role to play in organisations but managers can become too helpful that they get in the way of effective work. Oftentimes, the ways of working is an attempt to optimise for efficiency which ultimately affects the effectiveness of the team. The behaviours listed above might be appropriate in the complicate domain such as Manufacturing, where managers have a desire to maximise the utilization of “machines”. In the complex domain such as product development, these sorts of behaviours tend to have adverse effects on people and are counter-productive. People are a product of their environment and Managers micro-manage for a myriad of reasons, include pressure of deliver, lack of trust, immature teams among others.

Within a Scrum Team, there are no sub-teams or hierarchies.

An autonomous and self-managing team thrives when hierarchies take a backseat, allowing Scrum accountabilities to drive the ways of working. While organizational hierarchies persist, especially during the formation of Scrum Teams, it’s crucial to discuss privileges and their impact on a team’s ability to self-manage.

Privilege is when you think that something’s not a problem because it’s not a problem for you personally…

Hierarchical Privilege: This explicit form of privilege arises when a Scrum Team comprises employees with varying levels of seniority. Senior employees wield influence, sometimes making unilateral decisions that affect the entire team. For instance, a line manager, also a developer within the Scrum Team, might cancel a Sprint retrospective without consulting other team members.

With the recent news about Scrum Masters and Agile Coaches being laid off in organizations, the question that comes to mind is whether we are at the end of the road with regard to these roles that have in the past focused on building agile capabilities in organizations on a full time basis.

My opinion is that organizations will continue to have a need for people focused on helping teams to continuously improve their ways of working, improving team and organizational effectiveness.

Increasingly, I encounter developers who don’t seem to enjoy using the Scrum Framework to deliver software, and this is a cause for concern because I have fond memories from my days as a developer working on a Scrum Team. I relished the collaborative atmosphere within the team, where everyone supported each other in development, testing, deployment, and held a shared sense of accountability.

However, nowadays, I hear developers express their discontent with Scrum for various reasons, including:

The Product Backlog Refinement session is not an official Scrum event, but it is a crucial activity that helps Scrum teams to achieve a shared understanding of the product backlog items in preparation for the sprint planning. Teams that adopt the product backlog refinement as a complimentary practice tend to have smoother sprint planning events. The number of refinement sessions within a sprint depends on various factors such as the state of the product backlog, the maturity of the product, the Scrum team’s availability and experience.

The commitments contained in the Scrum Artifacts are arguably one of the important element of the Scrum Framework; these commitments when deployed as per the intentions of the scrum framework contributes to increasing the effectiveness of the scrum team.

I was asked to help out a Scrum Team that did not see much value out of a well-crafted Sprint Goal for their Sprints. In the sprint planning, the team would rollover every product backlog item (PBI) that was not completed in the last sprint, and the team would add a few more PBIs from their backlog on the ask of the team manager, who also attended the Sprint Planning regularly. Evidence provided in their product backlog management tool showed that the team had not for once completed all the PBIs in their sprint backlog in the last 6 - 9 months.

Selecting a product backlog management tool can be a daunting task, as there are a plethora of options available on the market. Some of the most popular tools include Jira, Azure Dev Ops, Kanbanize, Trello, and Rally, to name a few.

As a Scrum Master, it’s important not to view yourself as an administrator for the chosen product backlog management tool, but rather to focus on understanding how the tool can support the Scrum team to be an effective team. This post is a guide on how the product management tool should support the Product Owner, Developers, and Scrum Master in executing their accountabilities as defined in the Scrum Guide.

Should agile teams estimate defects?

This a one question that teams often find themselves debate and my perspectives has changed over the years on this. The short answer is … it depends on your team context and what you are trying to achieve with estimation.

Estimation is a practice that helps Agile Teams forecast the effort that is required to get a task done e.g. deliver a feature and as such, it contributes to capacity planning for the team. This implies that would be impossible for a Scrum Team to forecast how much work it can complete within a sprint if the Product Backlog Items are not estimated.