Agile project management is different from traditional project management. What we mean by that is in agile project management, the idea is to deliver the final product incrementally by following the Scrum Empiricism pillars:

Inspection, Adaptation and Transparency.

Whereas, most traditional approaches to product development set goals and note requirements at the very initial stages of the process with little room for adjustments. However, in agile there is no such thing as scope-creep since the project development team or sometimes called the Scrum team, are constantly pivoting upon getting the feedback from the Product Owner (PO) after every 2 weeks Sprint completion.

“Empiricism is a theory which states that knowledge comes only (or primarily) from sensory experience.”

Scrum delivers a transparent, potentially shippable increment (working software) that is frequently inspected at a minimum once per month by the Scrum team and stakeholders. Based on a review of the increment the product backlog is adjusted accordingly.

Additionally, the performance of the team and processes are also made transparent and are inspected at the same cadence in the sprint retrospective. Continuous improvement is achieved by adjusting how the team works from a communication, process, and quality point of view by planning improvement for the next sprint plan.

Let us examine a few key areas of agile project management and specifically focus on the role of a Scrum Master.

Besides the Scrum team that consists of cross-functional members of Developers, Quality Assurance (QA), Business Analyst and other Subject Matter Experts, there are 2 key roles that exist besides the Scrum team. These are the roles of a Product Owner and a Scrum Master.

Product Owner

• Conveys the vision and goals at the beginning of every release and sprint

• Maximizes the value of the work done by the development team, helping to create a high-quality product. This is achieved through managing the Product Backlog

• Keeps the backlog up to date, always based on client priority

• Represents the customer, interfaces and engages the customer

• To mention a few...

Scrum Master

• Good understanding of the Scrum framework (roles, artefacts and ceremonies etc.)

• Facilitates all the Agile ceremonies

• Removes team’s highlighted impediments

• Excellent in people and process management skills

• To mention a few…

For this blog, we are going to focus on the below mentioned list since we could go on and on.

A really good blog that was published that talks about challenges faced by a Scrum team can be found here.

How do we get management on board - still top down?

For any agile approach to work and be successful in any organization, it starts at the top - the management team. There must be clear acceptance, accountability and buy-in by the management before the marching orders are given to the rest of the organization.

Far too many times an agile approach fails, not because it was the wrong idea but because there was no appetite from the management, hence at the shop-floor, no one was willing to take a risk and fail. The management must communicate a positive, clear and consistent message to all the lines of businesses regarding agile, and to encourage all to adopt change and provide training where necessary!

Scrum team working as a one team and not with the mindset of ‘us & them’

As a Scrum Master, sometimes you get a feel of how divided and silo minded each team member is when you facilitate scrum ceremonies. This will need to change and try to move the team’s mindset to working together as a one-team and not as ‘us & them’.

As you know the usual phases of a new team put together will go through these phases:

FORMING | STORMING | NORMING | PERFORMING | ADJOURNING

Throughout the daily standups or the sprint planning sessions, you will hear team members talk in terms of: “It was the IT that did not provide access on time” or “This is a QA resource issue and nothing to do with development!”.

This is a challenge and one must start to educate all team members to accept that they are working together as one-team so each issue must be addressed like this: “We will work together to figure out how to test this story” or “I reached out to IT and we are trying to get access and will get back to this team by tomorrow” etc.

Development & testing (QA) members working in harmony

Each story created has two elements: the development part and then the testing part. We don’t have one story for development and one for QA. This means the story estimation also takes into account the effort needed to develop as well as to test it.

What happens in a normal execution is that the developer and the QA don’t work together as a unit and therefore, many stories are coded but not tested. So the stories to test start piling up while the sprint comes to an end. What happens to all the stories that were not tested and therefore not completed in that sprint?

The cumulative effect of stories piling up in the QA swim lane causes great issues when planning for work for the next sprint. The challenge being, does the Scrum team wait for QA to complete before new stories are coded or continue as usual? This impacts the team’s velocity as stories are not completed in any given sprint if the testing was not completed.

Development and QA resources in a Scrum team need to work together in harmony, as a one-team. This means, if the QA is struggling to complete the testing for a story, the developer helps out and tries to complete. Also look at ways to automate the testing model.

Scrum team not being co-located

Scrum principles dictate that the Scrum team being co-located will help the team to work and organize themselves as a single team and become more mature in agile.

Co-location provides an environment for the Scrum team to make the room they work in on a daily basis to become more ‘homely’ by adding sticky notes on the room walls etc. Also the room can provide private space for the team members to have collaboration, brainstorming, and whiteboard sessions. Furthermore, having the team members co-located will make it much easier for them to understand each other's energy levels and moods. This will help the team to have a positive energy at all times!

However, in the current situation we have people working remotely and therefore, as a Scrum Master you have to ensure that everyone feels comfortable, connected and delivers effectively. This will mean extra time must be given to team members, more collaborative sessions held and clear communication channels outlined so that people are able to reach out to each other. For example using tools like, Slack, MS Teams or Google Chat etc.

One person being both a Scrum Master and a Product Owner

As mentioned above, two key roles must exist on top of the Scrum team, a Product Owner and a Scrum Master. These are two roles cannot be one person!

The Product Owner and the Scrum Master have a distinct role in the agile process. The Product Owner makes sure to guide the Scrum team to deliver the final product incrementally by working on the most important stories. Whereas the Scrum Master facilitates and plays as a servant-leadership role for the Scrum team, by ensuring that agile principles are followed and adhered to.

A really good video on ‘In Agile, do we need a PO?’ can be found here.

Do we need a Project Manager as part of the Scrum team?

There are some situations where the management will feel that a Project Manager role should exist as part of the Scrum team. This should not be the case. In agile, we have a Product Owner, a Scrum Master and then the cross-functional Scrum team. We don’t need a Project Manager.

Traditional waterfall approach needed a Project Manager to complete and manage the sequence of tasks like: requirements gathering, analysis and design, build, test and deployment. At the same time, manage the project plan, project budget and track & report the project progress.

There may be situations where a Scrum team has an assigned Project Manager who may work with the Scrum Master to build a project plan and track the project budget. This scenario, obviously, demonstrates the fact that this organization has not fully understood what is agile and will require further coaching.

Lack of Scrum team participation

A good leader must not be a dictator rather a coach. Agile Manifesto prioritizes the human workforce over processes and tools. Thus the Agile principle encourages, motivates, supports, and trusts the people involved in the project.

However, an agile project generally abandons a leader who always needs to keep its resources on their toes! It is possible to face stubborn team members who are not easy going to adopt the deliverable frequent changes. Sometimes they are not even ready to present in simple daily standup calls! Hence, generating trust towards him/her and establishing him/her as a supportive leader sometimes become a mammoth task for a leader.

As a Scrum Master, start by assessing the team’s agile knowledge and create knowledge sharing sessions, either one-on-one or as a group. This will give the team confidence in you as a Scrum Master and will start to build trust that will move the team from storming phase to the norming phase.

Management demanding a Project Plan

There are some situations where you may be asked to provide a project plan for the product being developed. This scenario poses few challenges to you as a Scrum Master since in agile, the product is developed incrementally and any project scope or timelines are only possible to predict after say, 3-5 two week sprints (i.e. after around 10 weeks) of the Scrum team being engaged. Even after this period, the true nature of agile allows the project to be flexible in terms of scope creep and pivoting after getting feedback from the Product Owner.

Traditionally, timelines and resource requirements for a project are estimated at the beginning of the process. It is then decided how much can be achieved within these requirements. This approach sometimes poses difficulties as resources may be loosely estimated, often proving too optimistic or over estimated resulting in a large amount of funds not being used that could have been used to deliver business value elsewhere.

In agile, the project scope resides in the product backlog that is prioritized and worked on stories that will deliver maximum value to the customer. Timelines are planned once the Scrum team manages to stabilize on the velocity, i.e. the number of story points completed in a 2 week sprint. Once the velocity is determined, the remaining stories in the product backlog can be calculated to give a high level timelines - but remember: we are working in an agile environment and that means incrementally delivering the final product.

A Scrum Master has many roles to play when it comes to managing agile teams working in an agile environment.

In all cases, the Scrum Master will face challenges from many angles, for example to mention few:

• Lack of management buy-in

• Lesser Scrum team motivation

• Lack of agile knowledge

• Not an agile environment, i.e. traditional process and procedures not adjusted to accommodate agile ways of working

In many situations the Scrum Master continues to drive the change for the organization, coaching and mentoring individuals on the way and all the time, keeping an eye on the final deliverables.

Many people have shown interest in becoming a Scrum Master and have gone to great lengths to get certified as a Scrum Master. However, what makes an effective Scrum Master is the experience and the great people and communication skills. The ability to drive agile principles when no one is interested, demystifying agile myths and being focused in delivering the end product!